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

[Anil Madhavapeddy]

On 3 Jun 2013, at 14:22, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:
> 
> Le lundi, 3 juin 2013 à 11:59, Anil Madhavapeddy a écrit :
> 
>> 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
> 
> 
> I'm not sure I'm really convinced by that argument for me a package manager like debian (end-user oriented) is still something quite different from opam (developer oriented).  
> 
> Besides it's not because they are in the git repo that they need to be tied to the corresponding version checkout (keep in the repo a map from versions to checkout that have the correct metadata for the version). I quite like this idea of self-describing repos that you can navigate by following references to commits, it looks a lot like the web where you gradually follows references that are returned in the representations you ask.  Anyways.

Note that you can already do this if you really want. 

You just need the OPAM files in your repository in a packages/<version> directory, and you can just add the repo as a remote.  It used to work in early OPAM, but I stopped doing that a while back, and so haven't tested it recently.  Reports welcome...

> 
>> (Either way, I'd record your use case as a bug on the OPAM tracker to ensure we don't forget this conversation).
> 
> Tried to do that here:
> 
> https://github.com/OCamlPro/opam/issues/637
> 
> Initially I was planning to have an erratique-unstable repo with git package of all my software with special opam files to build them from a checkout. So that I could easily point to that for people to try the HEAD of one of my packages. I now realize that, as you mentioned before it's a little bit problematic, as it would force them to use the HEAD of all my packages.

It's still quite useful to have this around for the automatic testing system though.  We could easily configure OCamlot to 'subscribe' to your bleeding edge repo and attempt package builds whenever it has spare resources.  This way you get early notification of breakage rather than waiting for a release.

On the other hand, we need to be careful not to spam the hell out of people when they deliberately break interfaces :-)

-anil