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

Anil Madhavapeddy anil at recoil.org
Thu May 30 14:45:00 BST 2013

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:

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


More information about the opam-devel mailing list