[ANN] opam 2.0.7 and 2.1.0 alpha

We are pleased to announce the release of opam 2.0.7 and an 2.1.0 alpha.

This 2.0.7 version contains backported fixes, you can find more information in this blog post.

The 2.1.0~alpha contains many new features (cf. blog post or release note). If you want to take a look, a few glitches or regressions are expected, please report them to the bug-tracker.

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

20 Likes

Thanks for all the hard work that’s gone into this release, @rjbou @AltGr and @dra27!

To set expectations, this alpha release is for our users to smoke test the new features and let us know if they work for your usecases.

In particular, the opam external dependency management and support for recursive pins are both commonly requested features. Please do take this alpha for a spin, and report feedback here on this thread.

After this alpha is cut, there will be a sequence of beta releases (the number of which depend on the reported bug tail), and then the final opam 2.1.0 release. Your testing now will greatly help us put a quality release out of the door.

3 Likes

Would be nice to update also the scripts behind opam.ocaml.org:

1 Like

I had looked on the issue tracker on Github and found some somewhat fizzled out discussions on cross compilation support. Is there somewhere this might be discussed further? I didn’t see any mention of it in these release notes.

When using the new opam lock functionality, once we create a foo.opam.lock file, how do we use when we want to replicate the same opam environment in another pc?

Does the opam install . command check if there exists a foo.opam.lock file and use it or is it perhaps the opam switch create . checks for the existence of a .lock file. From the workflow point of view, I think it would make sense to generate .opam.lock files by default and for other commands to use it to generate a local switch environment.

Additionally, is there a way to define a development only package dependency in .opam file depends section, much like npm dev-dependencies section?

For example I want to add merlin, ocamlformat to the depends package list, however I don’t want the package to be built/installed/reinstalled when these dependencies change.

1 Like

You can use opam install . --locked to tell opam to use the lock file.

I’m not sure about the dev dependencies part.

1 Like

Ah, it seems it is an opt-in. Yep --locked works.

@AltGr wouldn’t it be better perhaps if this option is the default on opam install . and opam switch create . commands ?

I actually agree with the current opam install behaviour of not using the lockfile. Npm and Esy actually behave the same way–only install exact locked versions if you explicitly say so. This is done in CI/CD builds for reproducibility but for local development you would usually want to install whatever are the highest versions allowed by the opam file’s dependency bounds, so that your dependencies automatically get upgraded and locked on the upgrades.

Of course, this works because of the second part–npm install and esy install also automatically rewrite the lockfile with whatever the latest dep versions were installed. That is what I would recommend that opam do as well.

I believe this is incorrect, npm (and yarn) and esy use lockfile if it exists when running install command. You can force finding new solution with

esy solve --force

Ah, my mistake about Esy, thanks Andrey. Regarding npm, I believe it has the ci command for doing explicitly locked installs. So I assumed that the regular npm install command does update lockfiles i.e. dependencies. Maybe wrong assumption!

For yarn at least – according to this doc https://classic.yarnpkg.com/en/docs/cli/install/, yarn’s first preference is to use yarn.lock file if present.

@rjbou @AltGr and @dra27

Thank you for all the work on opam! I’m currently encountering an opam-installer compilation issue on the master branch at 3def1a6d1ff102aaa60 .

I’ve pasted the details on https://github.com/ocaml/opam/issues/4173

Thank you for this new version.

Generally, you should just reproduce the same installation steps as for the original installation
opam - Install

If opam was installed with the provided install.sh script, is it safe to upgrade opam using the package manager of your distribution, say, apt for debian? (which means, of course, creating a deb package, because opam 2.1.0 isn’t yet available on debian stable repo).

In general, is copying&pasting the whole ~/.opam directory a safe operation without any side effect?

SSL certificate expired on https://opam.ocaml.org

It’s not the first time this happens, maybe you want to setup autorenewal of LetsEncrypt? Assuming you are using Certbot, see https://certbot.eff.org/docs/using.html?highlight=renew#renewing-certificates

I just checked and there is a valid certificate on https://opam.ocaml.org now.

That being said I appreciate @XVilka’s suggestion to automate the process. People do get a bit nervous when their package hosting sites (which send a crazy amount of code to their local machines) start having certificate issues. Trusting the internet connection is important!

(Don’t mean to be critical of anybody. I am grateful for all the free infrastructure and software being provided to me)

@sid it was reported by someone else too: https://github.com/ocaml/opam/issues/4187

What I meant @XVilka is the certificate is valid now (so the problem has been fixed from the time you reported it). I was not implying that that it was a mistaken error report from your end. I agree that we should have an automated process or maybe if that automated process failed then there should be some more redundancy…

It also highlights the importance of having multiple mirrors, like many other languages/ecosystems have.

Upgrades are safe to a newer version. If you want to be cautious, you can backup you ~/.opam (that’s what install script do).
The only side effect of restoring an opam root directory (delete/copy/paste), is the loss of newly installed packages or switches. If you want to restore a backup to go back to an older version, be sure to change the binary before calling first time opam on the restored backup.