opam files now support a new x-env-path-rewrite field which specifies rewriting rules for the environment variable updates defined in the setenv and build-env fields. This is required for the Windows support. For more information see the blog post.
/tmp is now writable again in the sandbox, restoring POSIX compliance. Since opam 2.0.9 only $TMPDIR was writable
opam tree package.version is now supported, displaying the dependency tree of a specific version of a package
opam tree --recurse and --subpath are now supported for directory arguments
a new opam admin add-extrafiles command has been added to add/check/update the extra-files: field according to the files present in the files/ directory
a new opam lint -W @1..9 argument has been added to allow marking a set of warnings as errors if they occur
Releases: pre-built binaries now include the Linux/ppc64le and Linux/s390x platforms
as well as a bunch of bug fixes and improvements
You’ll find these features presented in the blog post, and for even more details you can take a look at the release note or the changelog.
We encourage you to try out this alpha release, instructions are detailed in the blog post, in particular for Windows where we now provide an experimental pre-built binary.
On Unix-like systems though, to upgrade, simply run:
Is it possible that opam itself is published as a package on opam-repo (like pip or npm), then I may use opam upgrade opam to try out the latest version without a bash-script?
opam-client is only a package providing a library. It doesn’t provide an opam executable.
There is currently no real equivalent of opam upgrade opam but the opam-devel package is the probably the closest. It provides a binary to be copied manually once installed.
At the moment though the 2.2.0~alpha3 version of this package still needs a review/merge from the opam-repository maintainers. But once available the following should be enough:
What’s the rational for having an “official” field which starts with x-? I thought that this prefix was for user defined fields that are basically ignored by opam.
This is the only way we found to add such feature without having to add a new proper field or change the syntax which would all require to bump the version all the way to opam 3.0.
As such the whole opam-repository would have to be upgraded as well and there would need to be some sort of automatic migration path like there was for opam 2.0 which requires a lot of more dev time that we do not have at the moment.
This field is “temporary” while we carefully design a set of features to be included in the next major version and make the associated automatic migration tools for opam-repository.