Hello, I’m opening this thread by requesting an advice from the community. Yesterday, one issue I’ve opened in the package base_bigstring has been closed with the feedback “Windows is not officially supported”.
I do not open this thread to complains about that: the maintainers are free to decide what they want to do with their code, and nobody can decide for them. That’s not what I want to discuss. (Just to clarify things, the issue mentionned that contribution are of course accepted, so there is no dead-end here. I’m just mentionning it here because this is the starting point of my request).
What I’d like to highlight is the cascading effect of platform support decisions across dependency chains: I’m not directly using base_bigstring, but I’m using a library, itself using base, itself using this package. In a general way, if one the element of the chain is not supported in a platform, this also affect all the depending element, and today we don’t have any visibility over this.
Most of the time, I’m coding in linux, then I’m using a windows VM when I need to target this OS, and it’s only at the end the process I’m seeing this kind of issue. I would be very happy if I had to way to check this from the very begining!
I’d be grateful if there were a way to declare target platforms (system, architecture, etc.) early in a project, preventing the installation of any package outside this scope. This would help inform end-users about potential incompatibilities when choosing libraries.
While I’m aware that the opam package catalog currently lacks this information and that the OCaml community’s resources are limited, I believe this is a worthwhile discussion. I’m open to feedback and would appreciate any insights on whether this is a valid concern.
For what is worth, I think that for the vast majority of libraries in OCaml the work needed to make them work on Windows (when they do not already out-of-the-box) is pretty minor, but oftentimes the maintainers work mainly on Un*x and do not have the time/inclination/knowledge to set up a Windows environment to fix the remaining issues. Sometimes maintainers are happy to receive fixes for Windows support, even if they will not work on them themselves… In this case, motivated users should seize the opportunity to help improve the libraries they use!
In other words, my opinion is that the way forward would be for all general purpose libraries in OCaml to support Windows as well as they support Un*x, rather than making it easier to mark them as not working on Windows. (I’m not saying that adding metadata to this effect could not be useful in some cases, but I don’t think it best addresses the needs of the ecosystem in general).
I’m pretty sure this can be checked using some kind of elaborate opam search --recursive on the opam-repository. Note that in the particular case you are mentioning it seems to be a larger restriction:
> opam info base_bigstring -f available
arch != "x86_32"
I just tried doing this: opam info dream -f available and got an empty result. It looks like this command literally parses out the named field and prints out its value. If it doesn’t exist in the opam file it prints nothing.
Does anyone know exactly how to make opam print the ‘effective’ platform support of a package taking into account all its dependencies?
One solution (or at least, a path with different problems :p) is to use the opam-cross-windows repository and cross-compile for Windows rather than using a VM. This is what the project I maintain has continued to do, despite better native support for Windows builds, for two reasons:
The opam-cross-windows repo maintains some patches that do not live upstream, such as restoring windows support for base-bigstring with this patch
My linux-based build machine can now build for both platforms, and it is easy to check if Windows will work: when adding a dependency, instead of opam install foo, I run opam install foo foo-windows. If foo-windows isn’t found, I detect that very early.
Of course, when a package does have good native windows support, maintaining opam-cross-windows gets easier for us, so these concerns are all still very real
I’ve tried the cross-compilation solution, but gave up because this open differents issues (for example when the packaging relies on dune-configurator).
Furthermore, I don’t think having a separate repository with patches available only here is a long term solution. This divide the efforts (and we only see how huge is this task when there is an event like the discontinuation of the fdopen repository), and does not benefits to the whole community.
If the base_bigstring maintainers are open to external contributions to provide Windows support, then maybe you could submit the patch to them? It looks fairly reasonable – not very painful maintenance-wise.
Thanks! In the discussion it looks like @jbeckford has a slightly better version of that patch, and that the maintainers are basically saying “we won’t fix it, but PRs are welcome”. Any volunteer to submit a PR for this?
The advice in this thread (submit the patches yourself) hasn’t worked for Jane Street. Every patch release of JS when I was active on Windows/OCaml has had at least one important package that was broken on Windows. Even base_bigstring : I submitted one PR to fix one Windows issue, and 3 months later the next patch release had a different Windows issue (the one in this thread).
JS does the right thing … they clearly state they don’t support Windows, and there is no reason for them to do the Windows testing that is required for “support”. But submitting a Windows PR when there is no Windows testing and the time-to-next-release is 3-6 months? That is the lovely game of Whac-A-Mole.
The original suggestion (mark the package as incompatible on a target X unless CI or a human gives it on target X) sounds like good software engineering.
OCaml is a niche language. Windows is a niche option within OCaml. Welcome to the world of niche^2
To be honest I dont expect things to improve going forward vis-a-vis Windows without someone driving it themselves. Only big ecosystems e.g. Rust seem to have (mostly) everything working everywhere. WSL is quite good and even does GUI. Could you distribute your application as a WSL application – it can be packaged reasonably transparently and interop is so good.
I think this is very pessimistic. I expect things to naturally move forward in the upcoming years because 1) opam now exists on Windows 2) packages are now being tested against Windows on the official opam-repository CI.
on target X) sounds like good software engineering.