OCaml for Windows installation confusion

I thought the standard way to install on Windows is reachable through the following path:

https://ocaml.org/
Up and Running with OCaml – OCaml
Up and Running with OCaml – OCaml
OCaml for Windows - OCaml for Windows

But the problem is the fdopen repo is scheduled to be deprecated in August ‘because dune works on Windows now’, with no obvious replacement or suggestion (except esy, which some may understandably not want to use).

And the opam site says Windows support is ‘planned’: opam - Install

What is actually the current supported way to set up OCaml (i.e. opam) on Windows? And can the OCaml website be updated with this method?

3 Likes

My guess is that the recommanded windows way is WSL2.

Probably, but if this is documented somewhere, I haven’t found a way to reach that from the OCaml landing page, and we need a clear path for newcomers to find it.

Wsl2 is easy-ish, but I’m also really surprised by that deprecation. If enough libraries have switched to dune, we should be able to create a non-cygwin windows experience by providing just opam and ocaml executables and building in the windows command prompt.

1 Like

Also Wsl2 is not an option for some windows environments because of (sometimes quite absurd) company security policies.

As far as I can tell until “untaring symlinks doesn’t work well on Windows · Issue #1315 · esy/esy (github.com)” is fixed esy is broken on windows. It certainnly is for me at least :slight_smile:

2 Likes

I had also seen that note about opam for windows being supported in 2.2 however nowhere could I even find a vague timeline for when that would be. I mean as far as I can tell it isn’t even at 2.1 stable yet. so I am assuming a long way away.

2 Likes

Apparently WSL produces Linux-only binaries unless you set up a cross-compiler? This is not really viable for newcomers.

I agree with @yawaramin that WSL (or better WSL2) is not a viable alternative to OCaml for Windows, as a cross-compiling setup is needed to generate Windows binaries.

In general, I also would appreciate some clarification on what exactly will be deprecated. To my understanding (please correct me, if I am wrong), the OCaml for Windows (btw this is really great work by @fdopen) consists of the following components:

  1. An installer, wrapping the original cygwin installer, providing the required cygwin deps, and including a windows binary of opam (also available separately)
  2. An OCaml compiler variant based on gcc-mingw (32 or 64 bit), e.g. 4.12.0+mingw32 or 4.12.0+mingw64
  3. A fork of the opam package repository opam-repository-mingw, that contains the aforementioned OCaml compilers and the packages of opam-repository. In the past some of these packages had patches to work in Windows, but nowadays the number of those packages is greatly reduced (if not 0?)
  4. An opam package depext-cygwinports with some helpers for dealing with the required Cygwin environment

As far as I understood the deprecation note (OCaml for Windows - The repository will be discontinued as of August 2021), it only affects component 3, which can be easily replaced with the upstream opam-repository as there are no differences of the offered packages (anymore). We just have to make sure, the OCaml compilers (component 2) are still available (which is mentioned in the post above). Personally, I would like to have them added to the main (upstream) opam repository.

I am also looking forward to the further development of opam, dune, etc. for even better Windows support, especially to get rid of the Cygwin environement.

2 Likes

Forgive the haste, a few points from the upstream opam-repository/opam side of things:

  • opam-repository-mingw isn’t disappearing in August, it’s just going to stop getting updates, so there isn’t a pressing “panic”
  • two of opam’s developers are on (well-earned!) holidays, but 2.1.0 is being tagged and released when they’re back next week. The focus for 2.2.0 is proper shell/depext Windows support.
  • upstream ocaml/opam-repository is not a drop-in replacement for opam-repository-mingw, but the patches in opam-repository-mingw are fewer than they used to be. The main thing (which I’m working on) is upgrading ocaml/opam-repository’s ocaml-base-compiler to support the mingw64 and msvc ports of OCaml directly.
11 Likes

Thank you. However if the repository won’t get any more updates from next month, that seems like a showstopper for OCaml usage on Windows to me.

I appreciate there is a lot of effort going into this. I wonder what the answer here is. Maybe it is ‘the OCaml Platform toolchain does not support Windows for the time being’. Maybe this is a chance for some organization to step up and contribute some Windows support.

We possibly have different definitions of “showstopper” :slightly_smiling_face:

After next month, packages which are updated and don’t require patches can be consumed by having ocaml/opam-repository as an “underlay” (i.e. you have ocaml/opam-repository at a lower priority to fdopen/opam-repository-mingw). Packages which carry patches are going to have figure out upstreaming those patches.

While there have been steps towards it, there has never been an official way to install opam on Windows.

2 Likes

OK, let me summarize the current situation then:

  • As of next month the opam-repository-mingw will stop being updated.
  • But users may be able to add a lower-priority overlay of upstream opam-repository to be able to use any packages which don’t need patching to work on Windows.
  • The official Windows installation method pointed at by the OCaml landing page, is marked with a big ‘deprecated’ warning. To a newcomer, this is a showstopper because they don’t know the above two points.

What I’m trying to say here is that there is no clear, supported, communicated OCaml Platform installation path for newcomers on Windows. Yes, as we know, there are workarounds and other options, but they are not really accessible to newcomers.

2 Likes

I totally agree. Maybe if there was a very clear concise guide that gave step by step instructions for how to get these things setup, but even suggesting overlays and underlays that need to be setup assumes far to much knowledge of the tooling.

One of the big problems is having too many paths and options. Its great that there are options but as a newcomer who just wants to write some code, more options are actually just worse. If one options is faster or slower or whatever it just doesn’t really matter. What does matter is the time from when you get to the ocaml website to when you run and see “Hello World!”

What most newcomers want is a simple guide that takes charge and just says:

This is the way: Do this, then this, then that, then compile and run this example program.
Happy ocamling
PS: there are other options if you care:[link]

Leave the ambiguity and options for the PS and if there isn’t one good way. Just be up front about it.
PS: It’s really great to see that there is progress and support for this kind of stuff, Its so nice to come to a community that is receptive, and actively to trying to improve like this. :+1:

3 Likes

If we are talking about beginners, OCaml does not support Windows yet.

As soon as we start asking people to install cygwin, wsl, or esy, (as opposed to distributing a .msi file) we’ve already lost. Too many things can go wrong and if you spend several hours trying to get these working and are ultimately unsuccessful, the experience can leave a really sour taste in your mouth.

For Windows, I wish ocaml.org should just say:

DON’T DO IT.

PS: If you really really really want to, here’s are your options:

  • cygwin
  • wsl
  • esy
  • etc

Things are expected to improve a lot for OCaml 5.0, but I’m not going to blame anyone if it is not quite there yet by 5.0. It’ll happen when it happens, and I don’t mind waiting another 25 years for beginner friendly Windows support. :grinning:

3 Likes

Some thoughts from a non-Windows user.

  1. I would hope there are a decent number of Windows+OCaml users out there.
  2. And among them, there must be a modest number who are experienced Windows developers.
  3. It seems like, if some number of them were to self-identify, perhaps one could arrange for the developers of the key components of an OCaml developer experience, to give those Windows devs “better support”, and thereby accelerate the process of getting Windows support to where it needs to be?

I’m asking these questions because, quite simply, if there aren’t any experienced Windows devs (if all experienced OCaml users are on Unix variants) then it’s hopeless to expect good Windows support. OCaml isn’t F#, and never will be. It’s got no company of the heft of MSFT behind it, and I doubt it ever will. [and frankly, I hope it never does: corporate “love” seems like the kiss of death, from my 20+ years of enterprise s/w development]

So, uh, maybe if experienced Windows devs (who would be willing to participate in a community to improve developer experience) could raise their hands, that might be useful?

Just a thought.

P.S. Why do I put things this way? Let us suppose that almost all OCaml developers are Unix hackers. Then it’s simply unrealistic to expect the OCaml experience on Windows to be acceptable: you have to have some critical mass of people who care about it, and are able to do something about it.

I’m actually much more comfortable with the idea of some corporate/organization contributing Windows improvements (as unlikely as that sounds). It may be a tall order to get experienced Windows users to contribute, and people should get paid for their work (ideally). Keeping in mind that David and others have made gargantuan improvements already, there are clearly some steps left to a seamless newcomer experience for OCaml on Windows.

If there’s anyone out there who wants to massively help OCaml adoption, improving dev experience for the biggest untapped dev market (less experienced Windows users)–or even paying someone to do the work–is the way to do it.

At LexiFi we have been writing OCaml under Windows for a long time and are quite experienced with it. I know of at least one other large industrial player that uses OCaml on Windows as their main environment cc @keleshev.

If I had to summarize the situation of OCaml on Windows I would say that once you get past the installation of the dev environment (C toolchain + Cygwin), the experience is quite similar to Linux. The compiler, standard library, dune and merlin, all work flawlessly on Windows. OPAM is not 100% ready yet on Windows (we don’t use it) but it has never been easier to work “monorepo” style using dune.

For beginners the main stumbling block is setting up the dev environment (C toolchain + Cygwin). On Linux installing a C toolchain is not needed because the compiler is installed by default, but this is not the case on Windows. As for Cygwin, it is strictly speaking only necessary when building the compiler itself. Once the compiler is installed you are free to never use Cygwin again…

So if you want a Rust-style experience for beginners you need to figure out how to provide a point-and-click installer that does the following things:

  1. installs the C toolchain,
  2. installs Cygwin and builds & installs the OCaml compiler using it
  3. installs dune and merlin

At this point you will be left with a very capable environment for writing OCaml programs using common editors such as VS Code.

Regarding 1. above (the C toolchain), there are two main options. If you want a completely freestanding C toolchain you must use the native MSVC compiler command-line tools, which you can get from https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line

If you are willing to use Cygwin for your day-to-day developing (as opposed to only using it when building the compiler), then you have a second option which is to use the mingw64 compiler. This compiler also produces native Windows binaries, but the advantage is that it is essentially gcc so you get an user experience which you may be used to from Linux. As it runs under Cygwin, this option may appeal to those that prefer to insulate themselves as much as possible from Windows specificities.

It depends what you mean by “on Windows”. If all you want is to develop “on” a Windows machine, yes by all means WSL is a good option. But the binaries you produce are Linux binaries, so they won’t run on Windows outside of the WSL environment.

Only if you insist on using OPAM for your development. It is perfectly feasible to develop on Windows “monorepo” style without using OPAM. The experience may not be as pleasent as it would be on Linux and depending on how much you rely on external libraries it may be more or less convenient, but it works quite well in general.

Cheers,
Nicolas

8 Likes

Thank you. This clarifies a lot. I still think opam is the key. It manages not only OCaml packages but also the compilers themselves. Once opam is working seamlessly on Windows, the experience should be as simple as it is on Unix. E.g.,

C:\> winget install opam
C:\> opam init
C:\> opam switch create ...
C:\> opam install dune utop ...
C:\> dune init ...

And as we saw in the opam site, that (or something similar) is still the plan.

4 Likes

See https://discuss.ocaml.org/t/ann-ocaml-opam-images-for-docker-for-windows for an easy way to get started on Windows using Docker.

Cheers,
Nicolas

2 Likes

Thank you. I think, as avsm said in that thread, that it will be critical to keep Windows support maintained in future. But I don’t think it should be the ultimate end-user (especially beginner) experience. The toolchain offered should be as close to native as possible, not force a new dependency i.e. Docker.

1 Like