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?
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 npmdev-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.
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.
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!
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?
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…
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.