[opam-devel] opam 2 containers/building toplevel

[David Allsopp]

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

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


David