Proposal: unified installer

Haskell Foundation
#21

A few random thoughts on this:

  • ghcup’s “installer” doc/website - https://www.haskell.org/ghcup/ - inspired by rustup, is quite nice. Regardless of which codebase serves as the foundation, it would be nice to keep this part.
  • While it’s not an issue for most users, it’s worth noting NixOS 20.09 doesn’t include ghcup. Maybe some more skilled nixos people can easily integrate that, but anyone on stock 20.09 has to put in work. Stack “just works” there (I wanted to see what ghcup was like or provided as a workflow).
  • Perhaps we can enumerate the feature that ghcup provide, and which are missing in stack? Maybe we could merge those into the unified installer.
  • Regardless of what codebase is used, stack should be included in the installed toolchain. I could not tell if ghcup did this (from the docs I read, it seemed like no).
3 Likes
#22

I’m very much in support of this. It sounds like both ghcup and stack are mostly there, modulo:

  • For ghcup: Windows support, installation of stack
  • For stack: Direct use of GHC, installation of cabal-install

I’m a little less sure why one would want to wrap ghc in this way. I actually am quite happy with how ghcup does this, where it does its job and then gets out of the way so that I can run the tools it installed. I can run ghcup set ghc 8.10.4 to set the default ghc in the path to a specific version, or I can just run ghc-8.10.4 if I don’t want to change the system state. My main concern with wrapping is the conceptual simplicity, but I also know that others will be unhappy with a state of affairs where running ghc might actually invoke something that downloads and runs software from the internet instead of just a locally installed GHC. I can definitely see that a management tool like stack or cabal might want to install a new GHC version in addition to libraries, but I think it’s the wrong choice for GHC.

3 Likes
#23

I’m not really a fan of the wrapper scripts at all. But there’s a problem on Windows that doesn’t exist on other platforms: it’s necessary to augment the PATH with additional information (msys2 paths) that is only known when you know which toolchain to work with. Personally, I think the right thing is to have a single executable like Stack does right now, and call stack exec bash/stack exec cmd if you want a shell with everything loaded up. I implemented haskwrap first as a proof of concept that the wrapper script approach works, but I’ve been advocating against this for a while.

1 Like
#24

Interesting. So it’s not possible to install msys2 on Windows, and then use it with multiple GHC versions?

If not, that’s very unfortunate. If GHC is so picky, I wonder if the right answer is just have each GHC version maintain its own private msys2 installation of the version is wants, in its own directory somewhere and only invoked by that version of GHC? Not ideal for space reasons, but if each GHC depends on different versions then the space savings are impossible anyway. Seems like the next best option. This could very well be implemented by something like a wrapper script, but that could remain an implementation detail hidden from users.

Reluctantly, I’d agree that something like an external “Haskell shell” (e.g., stack exec cmd) that sets up the path only for a specific GHC version is the third best option, if getting GHC to behave better isn’t possible. But it’s really quite ugly and IMO should be something of a last resort. Command line usage would be terrible if every program worked that way.

#25

It absolutely is! I don’t understand why we would want to wrap ghc to get this effect. We have plenty of windows toolchains that can use a single msys2 install with multiple versions afaik (e.g. chocolatey).

The windows PATH itself does not need to be augmented with the location of msys2. It suffices to feed the information to cabal as part of its config file, just as the cabal config can be augmented to paths for extra lib dirs, etc. Both the chocolatey installs and the old windows platform installers handled this just fine.

1 Like
#26

Thanks. That’s what I originally thought should be the case. I hadn’t tried using chocolatey with multiple GHC versions, so I wasn’t really sure how that would go. I’m relieved to hear it should work.

Speaking of chocolatey, frankly, it already works pretty well for Windows. It really should be part of the catalog of working installers, along with stack and ghcup. What I’m missing there is three things:

  1. It’s all a different way of doing things, that’s fundamentally tied to Windows. Would be nice to have the same story across all operating systems. (An msi file would still be Windows-specific, but at least you could install something and then use it to manage GHC and tool versions in the same ways cross-platform.)
  2. The repository isn’t controlled by the Haskell community, and this seems to have consequences. For example, I know I can use ghcup to try a GHC 9.2 prerelease right now, but I don’t know how to do the same with chocolatey.
  3. It seems to lack an equivalent to ghcup set. It’s not obvious (to me, as a non-expert user) how one is supposed to go about maintaining multiple GHC versions and switching between them to test in a variety of environments. Perhaps there is a chocolatey way to do this, but Haskell would need to make that more .
#27

You can just choco install multiple ghc versions side by side and pick them out by passing a flag to cabal. And choco is in the catalog of working installers, in that its now directly recommended by the downloads page (https://www.haskell.org/downloads/#windows) (and before it was recommended by the platform page, which is what the downloads page sent windows users to).

Also tamar, who maintains the choco for ghc, is also a core ghc windows contributor. Even though the repo (https://github.com/Mistuke/GhcChoco) isn’t under a haskell organization umbrella, I’m sure tamar would welcome contributors, and also would have no objection to moving it there if people desired.

#28

Sure, I wasn’t clear: I meant that I should have included chocolatey in my list of working installers earlier in the thread. Didn’t mean that it doesn’t work.

So right now, my list of installers and their weaknesses looks like this:

  1. stack:
  • No cabal-install.
  • Won’t set things up to use GHC without the stack build tool.
  1. ghcup:
  • No stack.
  • No Windows.
  1. chocolatey:
  • No Linux or MacOS.
  • 3rd party moderation needed to publish new versions.
  • UX for switching GHC versions not as nice as ghcup.

Still, the first two weaknesses in chocolatey cannot really be overcome, since they are inherent in the third-party tool and ecosystem. That still leaves the first two as viable code bases for building something more universal.

I’ve tried to be systematic in the list, but speaking personally, I think the ghcup UX right now is phenomenal, and I hope it can expand to include windows and stack, and do whatever else is needed so we can call the problem solved. I do think Stack’s feature of being able to install a new GHC when needed by the build plan is very compelling, and hopefully can be supported by the ghcup API that was mentioned earlier in this thread?

5 Likes
#29

I like your approach and list. I agree that one still does need to pass through 3rd party moderation for choco, but that’s the price of an integrated package manager.

I would note that all these nice ways of running command line tools to pick ghcs are useful to some people but everything seems to have gone afield from the original ask which kicked this whole thing off:

Some new users (and sysadmins) want everything for a default setup installed by a standard msi which can be both used in an interactive gui way that everyone is comfortable with and also scripted with standard tools for handling msis, and they want everything to be done in this fashion with no need to ever touch or consider a command line.

As far as I can tell, no proposal on the table just gives an msi that people click on and it puts the tools where they should go, and that’s it.

1 Like
#30

That’s being fixed as we speak. ghcup will allow to install stack.

That’s also being fixed. Probably not this week, since it requires more coordination.
The plan is to:

  1. port ghcup to windows
  2. figure out the MSys2 story (we already have a pretty clear plan)
  3. create a windows installer like rustup (an interactive powershell thing, not a GUI)
5 Likes
#31

Of course that page will stay.

That is fixed.

I haven’t heard any comments from the stack team that address this, so we’re assuming the current status is that ghcup will stay ghcup and stack will implement their own installer. As a result, the fragmentation problem will not be solved, contrary to what the blog post says.

This doesn’t seem like a major issue to me. Unification is an interesting goal, but user options are as well. I think the main confusion wrt installation is already solved on the new download page. In case there will be two separate general purpose installers, it may be restructured and users can pick one at random and be sure to have access to the entire toolchain, including stack, cabal-install etc.

4 Likes
#32

The fragmentation problem is caused by different installers yielding different results. Our aim is to have one or more ‘unified’ installers that yield a development environment that covers what ghcup/cabal-install and stack provide. The more installers that cover these core requirement for each platform the better.

Ghcup could quite easily integrate stack and vice-versa, provided neither breaks their existing schemes for managing ghc installations. In the long term it would be great to make this all better with perhaps a single tool managing the GHC installations, or at least some protocol to make it smoother, but it should be easier to work that out once we have done the initial pragmatic integrations.

1 Like
#33

When we say no cabal-install as a downside of stack, what exactly is meant by that? It’s relatively straightforward to write stack install cabal-install, and given stack exec --no-ghc-package-path zsh, you can use the stack provided ghc and the stack installed cabal-install binary pretty easily.

I currently use ghcup lately to manage cabal and ghc versions outside of stack, but for a long time, the stack based workflow for getting cabal-install and ghc was the only way I used either tool.

5 Likes
#34

Fair enough. I suppose what I meant was that using stack as an install tool and then running cabal and ghc is not really ergonomic. Running stack exec --no-ghc-package-path zsh might work, but it looks pretty ridiculous as part of general-purpose instructions on how to use Haskell. This is the same problem stack has as an installer for ghc: sure, you can run the ghc it installs, but the UI is geared around running everything via the stack tool. It bundles the installer functionality into a whole opinionated system on how to use GHC, which not everyone shares, and makes it harder to run GHC and cabal-install versus just installing them. Stack will also download and build cabal from source code, even though binary distributions exist for most common platforms, which is a minor point but an important one since building cabal takes a long time.

Again, I’ll repeat that Stack seems mostly there, if the installer can be separated from the build system.

2 Likes