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

[Anil Madhavapeddy]

On 3 Jun 2013, at 10:38, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:

> Le lundi, 3 juin 2013 à 09:38, Anil Madhavapeddy a écrit :
>>> 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?
> 
> I don't think that would really help as long as there is no mechanism by which a package can somehow auto-update its own description when it changes. That's the problem, not accessing the bleeding edge source, opam pin handles that very well.

The unstable repository I'm thinking of also has its OPAM description, url and information file.  The only difference from unstable to stable is that git:// URLs are allowed in the unstable repository.

This is similar to the xen-org repository at http://github.com/xen-org/opam-repo-dev, which they use for cutting-edge packages.  The danger of such a repository is that people neglect to test their stable tree, but OCamlot should help with that when it goes live.

> I think there's a use case that is not well covered here, which is pre-release/blocking bug in a package. What you really want is pin a package to the git repo but maybe only for a few days (like I wanted with ocp-indent), but of course the repos may not have the correct build instructions, so you want a lightweight way of being able to specify the new ones. For me it seems natural to try to lookup that in the repo itself.

In general, it's preferable to separate the packaging from the sources since they change at different rates.  For instance, Debian packages recommend the same thing:
https://github.com/OCamlPro/opam/issues/149#issuecomment-16041625

But the point remains that you can't just blindly pin a git repo to the bleeding edge in many cases, as it has some other dependencies that are also pulled in.  Why not just make it easier to apply a local patch to one (stable) package description?  That way you guarantee that you have all the prerequisites.

A script could do this easily: grab the latest stable description for a particular package, and create a remote with a slightly bumped version number (e.g. -local1 suffixed) and add a patch to the files/ directory.  When the upstream package is released, its higher version number will naturally take precedence.  No pinning required.

(Either way, I'd record your use case as a bug on the OPAM tracker to ensure we don't forget this conversation).

-anil