opam v2 switch init

opam-v2-switch-init.md

Switch creation and initialization in opam v2.

The first point for me is that we should as much as possible get to a system where the following basic sequences of steps are possible.

opam switch create bla               # Create switch
opam install non-ocaml-pkg           # Doesn't depend on ocaml
opam install ocaml.V.VV.V+variant

or

opam switch create bla
opam install non-ocaml-pkg  # Doesn't depend on OCaml
opam install mypkg          # Depends on OCaml, install an OCaml that
                            # sastifies them.

This a very clean conceptual model. Switches are just named and empty universes in which packages get installed on opam install.

There may be switch init facilities (see below) provided but by default nothing should be added and no compiler package should be needed on switch creation.

I think it would be good if we could try to realize this model. If it is not the case I would like to precisely understand why. This was discussed at length starting here:

ocaml/platform-blog#43 (comment)

and I'm still not convinced by the answer(s), especially the need for a config file. This all seems too ad-hoc to be the answer.

Now with the avent of local switches the bureaucracy of maintaing them is going to increase (only think about the dev tools merlin, ocp-indent, ... you'll need in each of them). I mentioned this more than once in discussions and I think one solution to this problem sketched below could be useful for the opam switch init story aswell.

Basically we need a good story to easily maintain and transfer switch (sub)state constraints.

The idea is to introduce a new entity let's call it a 'constraint set'. Roughly a constraint set is simply a named, opam-managed (or not) export file. It is used to define and record the partial state of a switch and refer to it via a name (TODO define state i.e. defines what can exactly be in these files).

Except for managing the names, at the operational level, there's nothing magic about them and all the operations available on them boil down to existing opam operations. Roughly, here's the command set. Below CSET denotes a constraint set name.

  opam cset list                # List the available sets
  opam cset apply CSET [SWITCH] # Semantics is `opam install` constraints
                                # and `opam var set` variables.
  opam cset add CSET FILE       # Add a new set defined in FILE
  opam cset remove CSET         # Remove the set CSET of the list
  opam cset show CSET           # Show the content of CSET

  opam cset snapshot [--add] CSET [PKG]...  # Create [CSET] as a snapshot
                                            # of current switch

  # Switch creation

  opam switch create NAME      # Empty switch or read a cset from .opaminit
  opam switch create NAME [CSET]  # Not [COMPILER] !

The cset listed by cset list are those that are in the repos, a possible ./.opaminit and the ones the user added himself.

It is important that we can distribute these files through repositories so that setups can be shared and signed among teams without pain.

A grab bag of notes:

• AltGr : "too much machinery" (I disagree, somehow they might solve many problems with little actual machinery). It seems he doesn't want them in repositories (disagree again, we should avoid as much as possible to have to juggle with external files). Also it's good if we can sign them. Ref. ocaml/opam#2649

• This also provides a lightweight way of solving bulk addition/removal of pins for sharing dev repos (avoids having to maintain a repository). Just provides a cset file users can add or cat c&p to their list. ocaml/opam#1734

• Need to define state exactly (packages installed, pins, variables) and ways of ignoring part of it, e.g. on snapshot ignore actual version, ignore variables etc.

• In general useful to juggle among switches via cset snapshot. E.g. solves: ocaml/opam#2211

• Could avoid the switch init files proposed in ocaml/opam#2930 as well as various other ad-hoc mecanisms like ocaml/opam#2930 (comment)