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.
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.
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?
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
depends section, much like
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.
You can use
opam install . --locked to tell opam to use the lock file.
I’m not sure about the dev dependencies part.
Ah, it seems it is an opt-in. Yep
@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
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)
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.