[opam-devel] opam 2 containers/building toplevel

[Louis Gesbert]

Le mercredi 1 juin 2016, 14:29:45 David Allsopp a écrit :
> 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/f740058a639306c093de3b4f7425a01747239e
> 97. Part of my reason for spending time last year implementing lib-pkg in
> the build system ...

Nice fix,  I'd gladly merge the PR

For lib-ext... well, we needed a build system:
- for OCaml
- with no dependencies

and it's just to bootstrap. Yes obviously, lib-ext is an ugly hack, and I am 
not proud of it; the doc+Makefiles makes sure you only use it for building the 
opam binary and not for usable libraries though

The previous solution was cleaner, but relied on ocp-build. Migrating to 
OCamlMakefile was a painful experience, but I can't see a better option 
around. Also, it manages to not be too much trouble to maintain.

It could actually make sense to have a real bootstrap and use a local opam 
repo; but this has big downsides as well.

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

Yes, not very friendly, but that's how I do that kind of thing 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?

Yes, at some point will have to switch the version of submissions to opam-
repository.