That’s true. I guess more broadly, with or without -B, there would be a little bit of work putting things in the right places, getting the settings file in place, etc. But this should be kept to a minimum, which is much less work and more surgical work whatever I think these installers do today.
I wasn’t aware of ghcup’s API, thanks for sharing. But keep in mind that the Stack codebase for this also already exists, has been in use for years, and already has full Windows support.
Sure, but stack isn’t just an installer, it’s bigger in scope and doesn’t expose an API that would let you build on it.
I’m not exactly sure what you’re proposing so far. And I don’t see how this will contribute to less fragmentation of installation methods.
I’d be interested to know what you think is missing from ghcup to be that “unified installer”. IMO, it is already that and supports alpine linux, freebsd, mac and even ARM and AARCH64. The reason that it doesn’t have windows support is pretty much that I don’t know how to do msys2 correctly and haven’t had anyone explain it to me, since I’m a windows novice.
As one of the cosigners on that proposal, and well aware that it’s been stalled for years, and also aware that you can write Windows installation tools without it, this gives me concern.
It isn’t a big showstopper. I’m aware that FilePath somewhat works.
3 Likes
Just for the record: I’m not the genesis of the request for a Windows installer based on the Stack codebase. I’d really appreciate if those people who have the need for it would speak up. I have no such need. I regularly use Stack on Windows quite happily.
Sure, but stack isn’t just an installer, it’s bigger in scope and doesn’t expose an API that would let you build on it.
That’s simply not true, the blog post mentions this directly. You can use Stack.Setup right now, and as a proof of concept I already did.
I’m not exactly sure what you’re proposing so far. And I don’t see how this will contribute to less fragmentation of installation methods.
I think my blog post was clear on my proposal. I’d prefer there was one installer codebase that handles all operating systems. But I’m fine sticking with Stack as-is for now, since I don’t have a gap. Others, however, have asked me to use the fact that Stack has already solved the Windows problem to help non-Stack users.
I’d be interested to know what you think is missing from ghcup to be that “unified installer”.
For one, a Windows installer.
The reason that it doesn’t have windows support is pretty much that I don’t know how to do msys2 correctly and haven’t had anyone explain it to me, since I’m a windows novice.
Right, and I worked at this problem about 7 years ago and figured out a method for installing the tools together that works. I also was a Windows novice.
I’d be interested to know what you think is missing from ghcup to be that “unified installer”.
I guess I could turn this around to you. What was missing in Stack’s installation features that you felt it necessary to create a new codebase for installing GHC?
7 Likes
Sure, but your blog post doesn’t mention what you envision that doesn’t already exist. So I’m not sure what new concepts or ideas it brings to the table.
If that’s the only thing then I think there are no technical controversies here and I’m happy to work on it.
Have you written down somewhere what the correct way of dealing with msys2 is?
For one, cabal-install support.
I wouldn’t mind if there existed a library that both ghcup and stack could use, but I don’t think either of the codebases are currently doing really the same thing. This would need a proper discussion on how such a thing would look like, what the exact goals are etc. The blog post doesn’t clear up those questions for me. That’s why I’m not sure how we are going to solve the installer fragmentation.
5 Likes
Is the punchline here that a little GUI wrapper around windows suport for ghcup might be a great idea for widening accessibility of windows users ?
1 Like
I wouldn’t mind if there existed a library that both ghcup and stack could use, but I don’t think either of the codebases are currently doing really the same thing. This would need a proper discussion on how such a thing would look like, what the exact goals are etc. The blog post doesn’t clear up those questions for me. That’s why I’m not sure how we are going to solve the installer fragmentation.
What I’m getting it with my response is that installing and even building GHC should be so easy that there isn’t much overlap in a stack or cabal-install installer anyways.
Secondarily, tying everything together, I think attempts to shove complexity under the rug for sake of new users will not succeed because that complexity will leak back out, and the best plan, even if it seems a bit more ambitious / slower, is just remove the extra complexity where it exists.
4 Likes
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
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
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
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.
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
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:
- 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.)
- 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.
- 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 .
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.
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:
- stack:
- No cabal-install.
- Won’t set things up to use GHC without the stack build tool.
- ghcup:
- No stack.
- No Windows.
- 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
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
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:
- port ghcup to windows
- figure out the MSys2 story (we already have a pretty clear plan)
- create a windows installer like rustup (an interactive powershell thing, not a GUI)
5 Likes
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
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
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
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