There is already a very good fork of opam for Windows here. My work has been on changes to upstream opam to improve the native experience. The 2.0 branch of opam builds on Windows, but the resulting binaries are not terribly useful (you can’t get past opam init). The master branch of opam now contains sufficient support to pass the testsuite (I haven’t yet ported the regression testing framework, although I don’t see why that fundamentally shouldn’t be passing too). At present I’m making a final push to complete the shell integration parts of opam init and opam env, at which point we can upgrade the ocaml-base-compiler packages in opam-repository with Windows build instructions.
After that, there’s a quartet of features which benefit opam in general, but are specifically useful for Windows:
- a replacement of base packages with base constraints, which is in progress in #3894. This actually provides a much more elegant solution to system compiler upgrades; for Windows, it’s original was that it permits upgrading and pinning FlexDLL, which is a C dependency of the Windows ports of OCaml.
- the introduction of a new predicate to limit automatic selection of packages by the solver, which will mean, amongst other things, that
opam install ocamlwill never select a variant or trunk compiler (not started yet, although the semantics of it are more complicated than the implementation). For Windows, it will mean that the switch will not randomly try to change the C compiler the switch is based on (i.e. switch Windows port). - build environments, which generalise the present “system” build environment. For Unix (well, and Windows 10), this would include having a Docker container associated with a switch and, for Windows, would also permit using separate Cygwin/MSYS and eventually WSL installations for package building. In general, it would also permit switches to have different depexts installed, since you’d no longer have to be tied to what’s installed on your actual system (that’s not started yet, either)
- package parameters. There have been various proposals on this before (including the one referenced above, which is actually superseded by the new predicate). I have a (new) prototype implementation which allows specifying things like flambda (and so, for Windows, some of the port selection information) as part of
opam install,opam reinstalloropam switch create. There’s a bit of tightrope to walk with this one, as changes here need to remain compatible with an opam 2.0 mainline repository.
It’s not clear exactly what’s going to land in opam 2.1, which is trying to head towards beta soon and 2.2 which should be relatively hot on its tail later in the year. I would add that reimplementing tools in OCaml, while a highly worthy endeavour, merely transforms the nature of the shell problem!