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

[Anil Madhavapeddy]

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

> 
>> The purpose of separating the source (from git) from the version number (in the package description or pin command) is to let the developer control constraints better.
> 
> I'm not sure I understand what you mean here. Basically the only thing I propose is to version the package descriptions in the source themselves and allow a checkout of HEAD to be able to figure out (from the file opam/versions) how to get to a specific version of the sources (and corresponding package descriptions).
> 
>> Pinning a newer version can result in recompilations due to dependent package constraints changing, so it's useful to be able to specify the version number during the pin.
> 
> 
> Here again I don't see how this is related to what I say, I didn't say "I don't want to be able to pin a package to a specific version" I said that in the current state of opam using pin with a git url is a fundamentally broken idea as it assumes that the checkout should be built the same way as the last package version opam has. 
> 

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

which would ensure that the 1.2.3 constraints are used with the source from the git remote.

What you want sounds like the job for an OPAM remote such as:
https://github.com/xen-org/opam-repo-dev

...where there a high-versioned packages with the latest constraints and dependencies for the master branch.  When a release is cut, the directory is transplanted into the main OPAM repository.

E.g.: https://github.com/OCamlPro/opam-repository/pull/762 (which came from Xen's opam-repo-dev).

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

-anil