On behalf of the opam dev team, I’m happy to announce the first beta release of opam 2.2.0.
What’s new in this beta?
opam init on Windows now requires you to choose which Git to use. Git for Windows is now recommended by default, though Cygwin’s Git can of course still be used. See the blog post linked below for more info on why choose one over the other.
when compiling opam on Windows with MinGW, the resulting opam binary now contains libstdc++ instead of requiring the DLL to be distributed alongside it or to be present in the environment during compilation
fix opam env containing carriage return on Cygwin - eval $(opam env) now works from a Cygwin bash terminal
as well as a bunch of bug fixes and improvements
You’ll find these features presented in the blog post, and for some extra details you can take a look at the release note or the changelog.
We encourage you to try out this beta release, instructions are detailed in the blog post, in particular if you’re using Windows for which we provide a – still experimental – pre-built binary.
On Unix-like systems though, to upgrade, simply run:
I’ve looked through several pages related to the project and I cannot find some information. Is there any expectation or understanding about when opam 2.2.0 is expected to be fully released?
Also, if there’s a roadmap or something that I’m missing or didn’t find, I’d very much appreciate a link.
There is no date no, it’ll be there when opam and opam-repository work out of the box on Windows.
On opam itself there is a fairly small amount of things left that you can see here:
On opam-repository the work on making the compiler packages compatible with Windows was fairly involved and is still in progress. There is no central place where the todo list for this is but there should be some news on what’s left to be done next week or so.
If you’re not using Windows however, feel free to think of this beta release as stable, all the alpha/beta releases have been extensively tested on Linux and macOS for the past 2 years
I’m not sure what symlink behavior you are referring to but keep in mind that MSYS2 (used by DkML) has a philosophy and implementation details that are quite different than Cygwin (the default for opam 2.2): https://www.msys2.org/wiki/How-does-MSYS2-differ-from-Cygwin/ … “Replacement of symlinks with copying, so that Windows programs don’t trip up on these files.”.
Aside 1: I have a few Windows patches for ocamlbuild that would require significant ocamlbuild rewrites (and some breakage) to upstream, and regardless it isn’t worth it to upstream because ocamlbuild looks like it is unmaintained. Anyway, the ocamlbuild patches are in https://github.com/diskuv/diskuv-opam-repository/tree/2.1.0
Aside 2: DkML takes every effort to avoid requiring administrative permissions. In many environments, especially schools and school-provided laptops, administrative permissions are a showstopper (at least where I’m from). Visual Studio is the last major piece of DkML that requires admin, and there is a workaround (using the same technique that Rust does) that may eventually be incorporated. Anyway, I hope we aren’t backing ourselves into a permanent one-way door by requiring admin.
Being one of the ocamlbuild maintainers (currently too busy on opam do to this work myself) I can assure you that upstream ocamlbuild with Windows support will definitely happen during the 2.2.0 Release Candidate period.
The current focus is on upstreaming the compiler in opam-repository, once that’s done and we have a Windows CI in opam-repository, we should be able to have someone working on upstreaming the patches to at least a couple of key packages which includes ocamlbuild.
I have made VS Code + Ocaml Platform + OPAM 2.2.0 + ocaml-lsp-server working. Simply add the C:\Cygwin\usr\local\bin to the PATH and launch VS Code.
But it has worked only after a VS Code update. It could be a coincidence. (My initial try was launching VS Code from Cygwin to be sure it has the right environment). The opam bin path is enough.
Emacs + merlin would need more tweak. The Cygwin Emacs is puzzled by Windows style path given by opam… and the Windows Emacs miss a /bin/sh required by merlin.
PS: ocp-indent also need the symlink support (CYGWIN variable + elevated rights)… but fails even with the real symlink configuration+privileges
