[ANN] opam 2.0.5 release

Ecosystem
1

We are pleased to announce the minor release of opam 2.0.5.

This new version contains mainly build updates & lint fixes. You can find more information in this blog post.

opam is a source-based package manager for OCaml. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.

6 Likes
2

What’s holding the windows release? Is it still planned?

3

MacPorts has been updated to the new version of opam as of a few moments ago; it may take a couple of hours for mirrors to synchronize.

4

If you check the OCaml, Opam repositories you may find the answer to your question:

And many more other small issues which are addressed one by one by dra27 mostly.

5

It seems that unix tools are the main issue with opam on windows? Is it true, @dra27? What could be done to help with that? Writing a pure OCaml opam-git, opam-patch etc?

6

As pointed by @XVilka, thanks to @dra27, opam is more and more windows compliant. We managed last weeks to merge a bunch of windows related PRs, that will be in the 2.1.0 beta release. I’ll let @dra27 give more information about next moves and needs.

7

There is already a very good fork of opam for Windows here. My work has been on changes to upstream opam to improve the native experience. The 2.0 branch of opam builds on Windows, but the resulting binaries are not terribly useful (you can’t get past opam init). The master branch of opam now contains sufficient support to pass the testsuite (I haven’t yet ported the regression testing framework, although I don’t see why that fundamentally shouldn’t be passing too). At present I’m making a final push to complete the shell integration parts of opam init and opam env, at which point we can upgrade the ocaml-base-compiler packages in opam-repository with Windows build instructions.

After that, there’s a quartet of features which benefit opam in general, but are specifically useful for Windows:

  • a replacement of base packages with base constraints, which is in progress in #3894. This actually provides a much more elegant solution to system compiler upgrades; for Windows, it’s original was that it permits upgrading and pinning FlexDLL, which is a C dependency of the Windows ports of OCaml.
  • the introduction of a new predicate to limit automatic selection of packages by the solver, which will mean, amongst other things, that opam install ocaml will never select a variant or trunk compiler (not started yet, although the semantics of it are more complicated than the implementation). For Windows, it will mean that the switch will not randomly try to change the C compiler the switch is based on (i.e. switch Windows port).
  • build environments, which generalise the present “system” build environment. For Unix (well, and Windows 10), this would include having a Docker container associated with a switch and, for Windows, would also permit using separate Cygwin/MSYS and eventually WSL installations for package building. In general, it would also permit switches to have different depexts installed, since you’d no longer have to be tied to what’s installed on your actual system (that’s not started yet, either)
  • package parameters. There have been various proposals on this before (including the one referenced above, which is actually superseded by the new predicate). I have a (new) prototype implementation which allows specifying things like flambda (and so, for Windows, some of the port selection information) as part of opam install, opam reinstall or opam switch create. There’s a bit of tightrope to walk with this one, as changes here need to remain compatible with an opam 2.0 mainline repository.

It’s not clear exactly what’s going to land in opam 2.1, which is trying to head towards beta soon and 2.2 which should be relatively hot on its tail later in the year. I would add that reimplementing tools in OCaml, while a highly worthy endeavour, merely transforms the nature of the shell problem!

7 Likes
8

Thanks for the detailed update on this topic.

9

Same with homebrew, it was merged 20h ago and binaries should be built sometime.