To be clear, I’m very much in favour of this (with my hat on as a busy professor type at Cambridge). I actually ended up deploying Jupyter notebooks for our course instead, and that eased a vast number of installation problems but at the expense of not having access to the full power of build tools.
All the attempts to build a Platform installer have stalled in the face of Windows support to date. The good news is that we’re targetting opam 2.2 (i.e. the next release after the current beta cycle is done) as the “Windows release”, where we will get proper upstream support (including opam and CI) for Windows. This in turn will fold in all the superb work @fdopen has done, and allow us to ship more official cross-platform installers suitable for use in (e.g.) a university environment.
I also have high hopes for the VS Code plugin we’ve been working on this year. Now that the basics are done, @rgrinberg and team have been looking into what more advanced UI integration might look like (for instance, an editor and lsp-integrated opam/dune ui is plausible to build). With this in mind, the workflow that @grayswandyr described can actually be compressed down to:
- install the OCaml plugin for your favorite editor among VS Code (or tracking-free variant)
- clone a teaching repo
There should be no need soon to install opam outside of the plugin (I’ve prototyped an opam tools plugin that I need to clean up for @rgrinberg that analyses a project and ensures that all the right tools are available in the local switch).
But… in order to deliver all this as a reliable binary installer, we really need Windows support. So that’s what the opam team is highly focussed on getting done as the sole purpose of opam 2.2. If we reject or delay other feature requests, it’s because we’re busy getting that done 