[opam-devel] Does pin git:// really make sense ?

[Anil Madhavapeddy]

On 30 May 2013, at 15:35, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:

> Le jeudi, 30 mai 2013 à 14:45, Anil Madhavapeddy a écrit :
>> That's precisely what it's intended to do. It's easy to extend the pin to add version numbers too (which may already be in trunk). i.e.
>> 
>> $ opam pin atdgen.1.2.3 git://github.com/mjambon/atdgen (http://github.com/mjambon/atdgen)
>> 
>> which would ensure that the 1.2.3 constraints are used with the source from the git remote.
> 
> If that's what its intended to do why not. I still think that it is quite confusing since the whole system will tell you that you installed 1.2.3 while it's not and as witnessed in my first email, it doesn't seem to work well in practice.  
> 
>> What you want sounds like the job for an OPAM remote such as:
>> https://github.com/xen-org/opam-repo-dev
> 
> Actually what I want at the moment is an easy way to install the repo version of ocp-indent. I guess since it doesn't install at the moment with pin the package description will have to be updated anyway. The idea is to avoid these things of becoming desynchronized.

I wonder if an upstream opam-repository-unstable makes sense here, which always points to the bleeding-edge version of a package.  This would also be useful for OCamlot to test, although very prone to breakage.  @dsheets, any thoughts on this?

The issue is that adding that remote would pull in every single bleeding edge package, without having a apt-style pin to only pull in a selected one.

On the other hand, it's quite common for bleeding-edge packages to depend on other unreleased packages, so this is necessary in the general case.

> 
> Because it's overkill for what I want to do now. And in fact I think these ideas could have lead to simpler workflows (to distribute your software just tell people to `opam add-pkg url-to-git-repo`) and a simpler design for opam (suppress the notion of opam repository, leaving only the notion of package and if your package descriptions differ from what upstream provides you fork the package with an automatic rebase on pull).  

I agree with the desire for simpler workflows.  For the moment though (given that the core of OPAM's design is unlikely to change drastically), it would be good to assemble these over what's already in OPAM 1.0.

For instance, you can create an opam-add-pkg shell script that creates a local filesystem hierarchy with just one package entry.   That maps to 'opam add-pkg <args>' if it's on your PATH when you invoke the opam binary.

-anil