Coq installer makes binaries available? about platform

[MSoegtropIMC]

In my experience setting the PATH might save some time in course A and put an additonal burden of 10x what was saved in course B which needs a different installation for whatever reason (say a HoTT course vs. a VST C verification course). Different professors even on the same university might provide specific installers for their courses or require specific different Coq versions. Over the life time of a computer / student setting PATH automatically never saves times. The PATH should only be changed by people who know what they are doing and then they know how to do it. As I said even Microsoft doesn't do it for their C compilers. Computer science students should be able to start a .bat file from a folder and / or the start menu.

[mgree]

I'll be content with whichever option, though I suspect there are lots of things that CS students "should be able to" do that some of our intro-level students will struggle with. I agree that it's impossible to please everyone here.

[JasonGross]

I don't think (a) is a sensible thing to do on Windows (there's no equivalent to /usr/local/bin unless you're using cygwin or MinGW (neither of which is required to install Coq). There should definitely be an option for (b) in the Windows installer, though, and both things seem sensible to do on Mac (though I'm much less familiar with Mac).

cc @MSoegtropIMC for Windows installer

[JasonGross]

A bit of Googling suggests that we might want https://nsis.sourceforge.io/EnVar_plug-in for having the Windows installer update the PATH (as suggested by this page) (But maybe see also https://nsis.sourceforge.io/Path_Manipulation ?)

[MSoegtropIMC]

I would rather suggest to provide a console with a specific setup (a batch file which leaves the console open when it finished) which provides whatever settings are required. This has the advantage that when you have 5 Coq environments, each one has its own console with its own settings. This is what e.g. Microsoft does to provide a way to run their compiler from the command line. This would also be similar to how Cygwin is typically started. For Windows this would be a no brainer as long as you don't want to copy the batch file around. If you want to be able to copy the console start e.g. to your desktop, the paths must be in the file (it cannot use its own file path) which means that the installer needs to write the file which is a bit tricky but not that hard either.

[JasonGross]

Couldn't we do both? A checkbox for set PATH for current user/all users/not at all, and also a console (maybe with checkboxs for "create a shortcut to the console on the desktop / start menu" like cygwin has)

[mgree]

My life would be somewhat easier if there was an option (checked by default) to munge the PATH, since it's one less class of mistake students can make (opening the wrong console). Having both wouldn't hurt, though.

A secondary issue is what happens to other users when a user installs Coq. I'm not an expert on the permission models of macOS or Windows, but I imagine administrator rights are necessary to munge other users' PATHs (which makes the symlink option appealing, at least on macOS).

[MSoegtropIMC]

I would say let's give the option I suggested a try. To summarise: what you need is an obvious way to start up a console in which the environment is set up such that Coq files can be compiled?

What I would suggest is to have a batch file called e.g. "Coq_Console_8_11.bat" in the root folder made such that it can be copied anywhere else. e.g. the desktop (that is the batch file will contain the absolut installation paths and not refer to its own path). I will also provide a start menu link to this file.

[mgree]

That should suffice, yes. If there was an option in the installer to create a desktop shortcut, that'd be great, too. :) Thank you!

My understanding of macOS is it's more common to put things in a special directory (e.g, /usr/local/Cellar or /usr/local/texlive) with symlinks in some other directory. Would that be the plan, or something else?

[JasonGross]

I am not sure who is in charge of the MacOS installer. I will ask on gitter.

[MSoegtropIMC]

Mid term I will likely take responsibility for the OSX installer - maybe this is a good thing to start with. I would probably provide a MacPorts port file. I am not a big fan of homebrew - it makes some top path prio system binary folders user writable.

[Blaisorblade]

FWIW, the macos installer isn’t an installer, just an image (almost just a tarball to unpack), so you’ll have to switch to an installer I guess.

[mgree]

Oof... that sounds like a lot of work for very small reward. 😒 We're avoiding CoqIDE in our course (Unicode and UI functionality issues), but I could imagine it being useful to have CoqIDE offer to install about symlinks on its first run.

[JasonGross]

but I could imagine it being useful to have CoqIDE offer to install about symlinks on its first run.

No, I think it would be better to have a separate script to do this. Also, I've seen fancy Mac installers where you just drag an App to a folder that is a shortcut to Applications or something, maybe it could also offer some shortcuts/links that you could drag to copy to the desktop or whatever?

[mgree]

I think having that script in the installer image is just fine. The macOS convention seems to be not putting things anywhere other than /Applications (though things are probably changing in Catalina).

[Blaisorblade]

Actual Mac installers exist, and they can change things outside /Applications; MacTeX is an example. Scripts to run through curl are also popular.

[mgree]

Oh, agreed---I was merely saying that it seems like a lot of trouble to switch to a .pkg- or script-based installation scheme just to achieve this goal.

[MSoegtropIMC]

Regarding OSX: From my (still limited) experience I would say there are two main variants: application packages which are simply moved to the Applications folder. Then there are packages which contain more command line tools, say OCaml. For the latter I prefer MacPorts. I am not sure what to supply for Coq, but I would tend to using MacPorts since Coq is mostly command line oriented. A MacPorts script is fairly free in what it does. MacPorts has its own build infrastructure for proving precompiled binaries. Homebrew is also an option, but as I wrote before it has the disadvantage that it makes (at least be default) system binary folders user writable. Finally there is the option of providing a shell script which builds Coq using opam reproducing exactly the released version. That might be a very short script.

[Blaisorblade]

@MSoegtropIMC The target audience is unfamiliar with the terminal. And IME students laptops basically suffer Byzantine faults.

For robustness, the installers should not have global side effects other than installing Coq, because those don't compose.

Here's a few options, judged on suitability.

A script unpacking the current image and creating symlinks (YES)

It can be done; brew cask install coqide already does it (implemented in https://github.com/Homebrew/brew/blob/b8c2e96ee6390803df7bbbc39e66d400b8ebcf52/Library/Homebrew/unpack_strategy/dmg.rb, tho there are probably easier ways).

A script unpacking a tarball (YES?)

Likely possible, similarly to opam (https://opam.ocaml.org/doc/Install.html); but would it work for GUI applications?

HomeBrew (no)

Insufficient on its own: not all users can/will install Homebrew (it's not compatible with MacPorts, and viceversa).
Already supports the latest version, and cannot support two versions.

MacPorts (no)

Insufficient on its own. Has all the issues applying to HomeBrew. But users might appreciate versions later than 8.8.2.

A script using opam (no?)

First, why would users have to compile Coq? That's a waste of time.
Also, that will fail on a fresh macos install, as macos doesn't come with a C compiler. And installing it via xcode-select --install is apparently not 100% reliable, based on the trail of questions on StackOverflow and elsewhere.

I also wonder how this would work with an arbitrary opam version and configuration, which you're not allowed to modify (possibly suffering from https://opam.ocaml.org/blog/camlp5-system/) — but I'm asking that on gitter.

[MSoegtropIMC]

@Blaisorblade : after gaining some more experience with OSX and various install methods I would propose to supply an application package in a disk image (.dmg) file which installs to the Application folder. This is similar to what we do on Windows and offers a similar user experience. If users would like to use command line tools, they would have to add the /Applications/CoqXYZ/bin to the path in their makefile or scripts. Again this is similar to what we do on Windows and shouldn't be that hard to automate in course supplied scripts. This has the advantage that it is easy to install several versions of Coq in sibling folders under /Applications.

In addition I will support an opam based installation with instructions on how to install opam via MacPorts and homebrew. Using opam to install Coq solves the version issues. I don't think it makes a lot of sense to distribute coq packages or coq itself via MacPorts or homebrew. The dependencies are complicated and it doesn't make sense to duplicate the information in opam unless one thinks about automating this.

ETA is Coq platform for 8.12+beta (will be about 6 weeks after Coq 8.12+beta core release).

[SkySkimmer]

ETA is Coq platform for 8.12+beta (will be about 6 weeks after Coq 8.12+beta core release).

@MSoegtropIMC so is this issue fixed?

[Zimmi48]

I don't think the specific use case highlighted by this issue is actually fixed by the platform macOS installer (which work the same as the previous Coq macOS installers). But I guess this issue should be transferred to the platform repository in any case.

[MSoegtropIMC]

@SkySkimmer : On Mac it is tricky, because the contents of an application package is not (usually) visible, so one can't put anything in there a non expert user can be expected to find. What one could do is to include a shell script at the top level of the .dmg file one can move e.g. to the desktop.

But in general I would say there is no bullet proof way to supply a working shell environment for people who don't know what a shell is.

It might be easiest to explain what path command you have to issue on macOS or Windows.