[opam-devel] OPAM 2.0 features

[Louis Gesbert]

> Biggest feedback at the moment is that compilers-as-a-package is a fabulous
> innovation – I had originally expected to need to add lots of horrid
> Windows (and OCaml, therefore)-specific stuff to the OPAM program, but in
> fact all I've had to do is add generic features to OPAM and then handle the
> rest in the package itself, which is great!

That's good to hear :)
 
> > The "target-filename" part being optional. See for example
> > http://opam.ocaml.org/2.0~dev/packages/ocaml/ocaml.4.01.0+BER/opam
> 
> Ta, I came across it subsequently too! I've extended it (or rather, will
> shortly extend it), to allow it to refer to the URL of another package, as
> the ocaml package needs to pick up the sources of the flexdll package
> installed just before it in order to bootstrap correctly.
 
Hm, that seems a bit ad-hoc and introduces metadata dependencies of a new 
kind. What if flexdll has a git url or is pinned locally ?

> I've gone with the command line options for now (with an error check to
> ensure that they're only given when installing a switch). At the moment,
> they define three global variables switch-cc, switch-libc and switch-arch
> which are only available during the switch installation, so if they want to
> be kept, the compiler package has to capture them in its own .config file.
> ocaml.system remains a horrible hack under this mechanism (the script
> identifies that it's in a switch named "system" and uses that fact to probe
> switch-cc, switch-libc, and switch-arch...)

That would likely break `opam switch foo --alias-of system`. Adding `--set-
variables <bindings>` to `opam switch install` would be a good first step, and 
if we find suitable sugar later on we may add it.
 
> It's not particularly pretty, but it does seem to work in the absence of
> something more general for now. In particular, I've restructured the base
> packages and added a package called compiler whose purpose is to store
> variables (in particular, compiler:o, compiler:so and compiler:a giving
> important file extensions for object files, etc., which are necessary for
> writing generic package specifications). The only bug I had to fix with
> that so far is to thread the config files correctly through parallel_apply
> (before they were only re-loaded at the end of the installation), but there
> is a comment in the code that you already aware of problems there!

hm, forgot about that TBH, I'll need to check :) 

> > Yes, just philosophical, there is no constraint here besides the
> > arbitrary
> > "I don't want to recompile the compiler, ever".
> 
> 
> I've spent the last couple of days working through this, and I think it's
> definitely worth relaxing that restriction. I've altered opam switch so
> that only the root package is the compiler package – so only ocaml.version
> is in the compiler section of switch-state. Have a look at this
> transcript:
> [snip]
> 
> That seems a potentially very useful thing to be able to do – and you don't
> lose the safety of the "compiler" packages – opam remove flexdll (or
> base-unix, etc.) will still complain that this would involve removing the
> compiler:
 
> [opam:4.02.0] [git:windows] C:\DRA\opam\src>opam remove flexdll
> Your request can't be satisfied:
>   - Package ocaml is part of the base for this compiler and can't be
> changed
 
> No solution found, exiting

Note, though that even with the current system, the restriction that compiler 
packages are immutable is somewhat lifted if you pin the package: so the above 
should work without changes (I haven't tested pinning one package of the 
"compiler packages" set and recompiling its compiler dependents though)