feature request: support co-installation of different versions of a same package

[UnixJunkie]

Hello,

I know this might not be easy to do, and might have deep implications in the OCaml tool-chain, but, for end-users of OCaml software, this is a highly desirable feature.

This would allow to have "old opam packages" still being able to install, despite
having recent versions of its dependencies already installed in the current switch.

Nix can do it. Can't we steal this feature from nix? :)

Thanks,
F.

[dra27]

If you install two versions of the same package to the same switch, what do you expect ocamlfind list to do?

[rjbou]

Why do you need them in the same switch ?

[UnixJunkie]

If you install two versions of the same package to the same switch, what do you expect ocamlfind list to do?

I don't expect anything special.
I just would like that everything "just works" (tm).

[UnixJunkie]

Why do you need them in the same switch ?

If it "just works", I in fact have no strong requirements that they are in the same switch.

[rjbou]

You can already have several versions of a packages installed on different switches.
Then, if you want to test without switching switches, you can use the command opam exec --switch <sw> -- <cmd> to have the good environment.

[UnixJunkie]

Ok, but it should work out of the box.
For example, opam should create a new, probably uniquely named switch in case a given package
(or version of it) cannot install in the current switch.
Also, I guess this needs some sharing across opam switches so that things are not duplicated like crazy and we end up with a very large ~/.opam when using this feature.

[rjbou]

imho opam shouldn't have this behavior directly, but it can be integrated via a plugin (see otopop that wraps the install). In a more light way, it can even be scripted, using install options, switch export/import, and return codes.
For the non duplication, there is a script that can be used in opamrc to activate a binary cache.

[UnixJunkie]

This feature would be utmost useful to non OCaml experts (i.e. just end-users of some OCaml software; take coccinelle for example).
If something like opam-depext is provided (that self installs when needed, etc), that would be nice.

[dra27]

Surely local switches are a better fit there?

[dbuenzli]

End-users of OCaml software should not be using opam but their system package manager and/or distributed binaries.

[UnixJunkie]

Daniel, you are a real day saver.

[dra27]

That’s not always true (tool may be not packaged, or the OS may package an older or non-bleeding edge version) - especially with things like coccinelle which are development tools. I see the use-case @UnixJunkie is after (and feel the same thing when forced to use the package manager of programming languages I don’t use), I just don’t think there’s anything to do beyond having coccinelle’s README include the incantation for setting up a local opam switch for its dependencies.

[UnixJunkie]

<joke-mode>
Here is the proposed CLI interface:
opam install --whatever-it-takes <some_package_known_to_opam>
</joke-mode>

[dbuenzli]

That’s not always true (tool may be not packaged, or the OS may package an older or non-bleeding edge version) [...]
and feel the same thing when forced to use the package manager of programming languages I don’t use

That speaks for itself.

Don't require end users to learn the idosyncrasies of the underlying technology you are using if it doesn't appear at the ux level of your product. This whether your tool is a development tool or not and whether it's packaged or not.

[dra27]

This discussion started as a feature request requiring changes across the entire toolchain (and which wouldn't begin with opam) and then morphed into a fairly amorphous UX question. Given the increasing availability of other caching systems (e.g. Dune's cache; opam-bin) and the slow steering of opam towards local switches and even potentially to be driven by build systems directly, I'm going to close this.