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

Daniel Bünzli daniel.buenzli at erratique.ch
Thu May 30 15:35:24 BST 2013

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.

> Why not just use the existing OPAM facility for multiple package repositories (including local ones) instead of complicating the core?

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).  


More information about the opam-devel mailing list