[opam-devel] opam 2 containers/building toplevel

[Anil Madhavapeddy]

> On 1 Jun 2016, at 15:29, David Allsopp <dra-news at metastack.com> wrote:
> 
> Anil Madhavapeddy wrote:
>>> On 31 May 2016, at 14:36, Louis Gesbert <louis.gesbert at ocamlpro.com>
>> wrote:
> 
> <snip>
> 
>>> The issue with `make lib-ext` may be that `opam-admin.top` can't find
>>> the proper opam libraries installed. The Makefile in `admin-scripts/`
>>> has a quick hack to build bytecode versions, but that reiles on
>>> `ocamlfind` to locate the installed versions of the dependencies; it
>>> wouldn't be difficult to improve it to work with `lib-ext` though.
>> 
>> It would be very useful if they could work with lib-ext and the toplevel
>> be built by default.  Right now there is some oddness where the extlib
>> interactive installer is run if I build `opam-admin.top` manually, so I
>> gave up around there.
> 
> lib-ext isn't very well-conceived/constructed, IMNRHO! See https://github.com/dra27/opam/commit/f740058a639306c093de3b4f7425a01747239e97. Part of my reason for spending time last year implementing lib-pkg in the build system ...
> 
> I then hacked admin-scripts/compilers-to-packages.ml and changed the #directory entries to include src/{core,repository,format,tools} and src_ext and can run that script which I used to replicate the next branch on opam-repository and so rebased to create https://github.com/dra27/opam-repository/tree/next-windows (I've been doing a lot of work locally, which is why it's lagging behind master at the moment). 

This does sound like the right approach indeed!

> 
>>> Now, for scripts that get generally useful and somewhat stable, it's
>>> perfectly fine to migrate them to be part of opam-admin. Moving the
>>> scripts to their own repo would also be fine if they reach a critical
>> weight.
>>> 
>>> Should we improve compat of the Makefile and/or move the 1.2->2.0
>>> functionality to opam-admin ?
>> 
>> For the purposes of container-based testing, it would be great if we could
>> move the essential functionality into `opam admin` directly.  This will
>> let me insert in the right `git clone / opam admin upgrade` runs into the
>> CI scripts so that OPAM 2 is easy to test for end users.
> 
> compilers-to-packages.ml will be a one-time thing, though, surely? Once OPAM 2 goes live, surely the main repository will need to work in reverse, back-porting an OPAM 1.x.y repository?

Yes but the functionality still needs to be in opam-admin for other local repositories to be upgraded by their admins.  For instance, we maintain several remotes internally at Docker with pinned versions that we use for reproducible binary builds, and those would need to be upgraded when we migrate to OPAM2. 

Anil