[opam-devel] Opam ocsigen repository

[Amir Chaudhry]

On 19 Feb 2015, at 17:21, Anil Madhavapeddy <anil at recoil.org> wrote:

> On 19 Feb 2015, at 17:05, Drup <drupyog+caml at zoho.com> wrote:
>> 
>>> Out of curiosity, what was tedious to maintain there?
>>> 
>>> One thing that's come up in both Mirage and XAPI is to have a script that 'splices' a released package from one remote to another.  That would let us upload stable cuts to a working remote, and then move them over to opam-repository.  Would that sort of thing help Ocsigen as well?
>> The opam ocsigen was never done for stable packages, opam-repository is already there for that. We did it when eliom 4.0 was cooking, and the previous eliom version of eliom was very old, so it was necessary even for beginners to use the dev versions of all the packages. opam pin was not very mature at the time.
>> 
>> Now, with opam pin, we have opam files in each package repository, and we would need a mostly-the-same but slightly-different set of opam files in the opam repository. In practice, the opam repository was never updated and was kept out of sync all the time, confusing everyone.
>> 
>> Also, the need to use dev versions is far less important, since the released versions are much closer to the dev versions. And with `--dev-version`, pinning dev versions is really easy.
>> 
>> Basically, it's a mix of inconvenience to maintain and lack of necessity. We could probably have automate it (probably not completely, though), but in the end, it's not really worth it.
> 
> Makes sense.  The use of the remote is useful for stable packages when you need to 'gang schedule' a bunch of constraints and have a place to put them to test for breakage in the broader repository.  I'm considering a model like this for the Core/Async package updates, since they typically break a few of the dependent packages in the OPAM repository after they are merged.  It would be nice to have a consistent staging area where such errors could be sorted out ahead of merging into mainline.
> 
> This problem may come up for Ocsigen as well as its number of libraries grows…

To add some more context to Anil's comment, we've also discussed this kind of model for MirageOS.  It would create a staging area for some wider testing to take place, beyond the current tests on individual libraries.  It might also allow a place for developers to get 'cutting-edge' package sets, by adding the remote -- as opposed to 'bleeding-edge' :) 

Some notes on the discussion are at: http://openmirage.org/wiki/weekly-2015-02-11#ImprovingQuality

Amir