Windows Support

changed the description

Afaik no one is working on a windows version. I myself have not enough knowledge of windows as a platform, so I can't be of much help, except review the result.

Also, what are some issues that I might face trying to work on this support (of course, if you can think of any)?

General "shell" scripting issues. We don't want surprises for the user... the worst case is that we remove or overwrite files that should not have been removed/overwritten. Double check everything, don't assume anything.

If no one is currently working on it, can you please let me know how you would like to proceed if you were to accept a windows version?

You just put up a PR and we test and discuss it. What I'm also wondering is how would windows users get the bootstrap script in the first place. Does powershell have something like curl baked in?

Afaik no one is working on a windows version. I myself have not enough knowledge of windows as a platform, so I can't be of much help, except review the result.

No problem. I will use ghcup's script as a guide and try to just translate all of it to Powershell.

You just put up a PR and we test and discuss it. What I'm also wondering is how would windows users get the bootstrap script in the first place. Does powershell have something like curl baked in?

Ok, copy that.

You just put up a PR and we test and discuss it. What I'm also wondering is how would windows users get the bootstrap script in the first place. Does powershell have something like curl baked in?

Yes, they do, and they also call it curl (actually its an alias). Here is the link of the actual command: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-6

While merely installing ghc and cabal from the bindist tarballs is relatively easy to implement in powershell; the bigger problem is dealing with setting up a sane msys2 environment to provide a good user experience. This is something that Tamar (who's also been putting quite a lot of work into the Win32 support in GHC and Cabal proper as well) has been investing time on to get right in Chocolatey's packaging of GHC+Cabal (see https://hub.zhox.com/posts/chocolatey-introduction/)

Given there's Tamar's chocolatey packaging of Cabal+GHC I wonder if porting ghcup to Win32 solves an actual problem that isn't already addressed by chocolatey (I'm not saying there isn't any; I'm just not sure what problem it'd solve).

Sorry, I am a bit confused about why would we need msys2 if users were to run the installation in powershell? We could even convert the powershell script to a ".exe" file like Rust is currently doing.

I've used rustup on windows, linux, and mac. One point that I really appreciate about this tool is that I did not have to figure out what other tools that I needed in order to install Rust on each platform. So, I think that for the sake of consistency having support for windows might be important.

We will probably have more people coming from Rust trying out Haskell now - since this tool is taking its inspiration from rustup it'd be nice if ghcup provided similar support.

Given there's Tamar's chocolatey packaging of Cabal+GHC I wonder if porting ghcup to Win32 solves an actual problem that isn't already addressed by chocolatey (I'm not saying there isn't any; I'm just not sure what problem it'd solve).

I am not too sure how to answer this... However, I think that support for linux and mac is already solved as well using stack or Haskell Platform so I don't really view this project as solving any problem, on the contrary, I see it as a better/lighter option coming from the Haskell group.

Lastly, I don't actually really use windows but in the README "contribution for windows are welcome" was written so I just thought that I'd offer my help.

Sorry, I am a bit confused about why would we need msys2 if users were to run the installation in powershell? We could even convert the powershell script to a ".exe" file like Rust is currently doing.

Because you wouldn't be able to use configure based packages or packages requiring a unix shell without it. Essentially you'd be setting back Windows installs years. This is the reason Haskell platform and stack both install msys2.

A Haskell install on Windows without a properly configured msys2 is just useless for the average user who just want it to work.

I've used rustup on windows, linux, and mac. One point that I really appreciate about this tool is that I did not have to figure out what other tools that I needed in order to install Rust on each platform. So, I think that for the sake of consistency having support for windows might be important.

Rust doesn't have nearly the same set up as GHC. So a similar tool doesn't make much sense. Rust is it's own fully contained toolchain and doesn't require configure for package installs, or pkg-config. The requirements are completely different.

I am not too sure how to answer this... However, I think that support for linux and mac is already solved as well using stack or Haskell Platform so I don't really view this project as solving any problem, on the contrary, I see it as a better/lighter option coming from the Haskell group.

Then you've never used Haskell Platform on Windows, As someone who has contributed a not insignificant amount of the code in the Windows version of GHC I have seen how many bug reports still get filed because of people not reading the "step 2" on the Haskell Platform page. Platform still requires manual user intervention, which is why it's an inferior approach.

ghcup may be a lighter system, but it's also less secure, less supported on the platform (no AD deployment support, no boxstarter or Nuget deploy support etc).

Also as far as I'm aware, even though ghcup is hosted on haskell.org it's not affiliated with GHCHQ. I see it as not any more "official" than chocolatey.

So far the only "benefit" you've mentioned of ghcup is that it's called ghcup, which isn't a sufficient reason to provide yet another half working solution to install GHC on Windows. I certainly don't want to have to field more bug reports that will arise from this.

This is the reason Haskell platform and stack both install msys2.

So why can't ghcup install msys2?

ghcup may be a lighter system, but it's also less secure, less supported on the platform (no AD deployment support, no boxstarter or Nuget deploy support etc).

Less secure than what?

Also as far as I'm aware, even though ghcup is hosted on haskell.org it's not affiliated with GHCHQ. I see it as not any more "official" than chocolatey.

Correct, ghcup is not an official project. Like stack or any other solution. However there is great motivation to make it as compatible with 1. the officially provided tarballs and 2. cabal-install.

So far the only "benefit" you've mentioned of ghcup is that it's called ghcup

The main advantage is that it let's you easily switch between ghc versions and manage multiple such installs at the same time. Does chocolatey provide the same or only the latest GHC version? If only one, then it doesn't provide the same functionality.

So why can't ghcup install msys2?

You can, then you have to maintain it as well. Dumping an unmaintained tarballs on the user would just give them an unusable install system once the CA-certs expire or the pacman root sigs change. And simply installing msys2 is not enough, you have to configure e.g. Cabal to be able to use it.

Less secure than what?

Than chocolatey which is what I'm comparing it against. As far as I'm aware ghcup doesn't provide any validation of the files it downloads and provides no protection against simple attacks such as MITM for starters.

Correct, ghcup is not an official project. Like stack or any other solution. However there is great motivation to make it as compatible with 1. the officially provided tarballs and 2. cabal-install.

Chocolatey also uses the official provided tarballs, coincidentally it also allows you to specify your own hashes to check against if you don't trust the hashes provided by the package.

Does chocolatey provide the same or only the latest GHC version? If only one, then it doesn't provide the same functionality.

Chocolatey provides every single GHC released for Windows all the way back to GHC 6.10.1 and Cabal 0.6.0 any one of which can be installed and managed side by side.

Not only that they're configured to work out of the box taking into account the particularity of some older releases including the ones that were installers and not tarballs. It also supports the ability to install nightlies and pre-release alpha and betas.

You can, then you have to maintain it as well.

Of course. Is there anything wrong with that?

As far as I'm aware ghcup doesn't provide any validation of the files it downloads and provides no protection against simple attacks such as MITM for starters.

It doesn't provide checksum validation yet, but it's not difficult to implement. I haven't done it yet, because doing it properly involves verifying GPG signatures of the upstream authors of the tarballs. And as soon as GPG enters the picture, things become complicated, unless you do it half-baked.

Chocolatey provides every single GHC released for Windows all the way back to GHC 6.10.1 and Cabal 0.6.0 any one of which can be installed and managed side by side.

The idea behind ghcup was to make installation as simple as possible for people who can't use their distro PM (happens often on Linux) or who don't want to. I've used chocolatey myself, but I can't say how comfortable a Windows haskell user would be with it, if he/she has never used it for anything else.

As such I don't really have a strong opinion on whether ghcup should support Windows. I can only say that such an implementation would have to satisfy the project standards.

Of course. Is there anything wrong with that?

Yes because people tend to do it wrong. Which is why on chocolatey it's a community maintained project with multiple people and chocolatey core who use it daily. Given the fact that ghcup doesn't support windows now, I suspect no one here actually uses Windows.

The idea behind ghcup was to make installation as simple as possible for people who can't use their distro PM (happens often on Linux) or who don't want to. I've used chocolatey myself, but I can't say how comfortable a Windows haskell user would be with it, if he/she has never used it for anything else.

I find it hard to believe that people would be more comfortable in using a script they've never heard of maintained by a much smaller set of people over something that I am pretty sure has a much larger order of magnitude of users and trust.

Ultimately this discussion has no point so I will stop here. If people want to use ghcup on Windows that's their choice. I don't have to like it, but I don't have to support it either.

Which is why on chocolatey it's a community maintained project with multiple people and chocolatey core who use it daily.

That's a "social" argument and not very interesting. If you believe that chocolatey does it correctly, please provide links that describe their approach of automating gpg signature checks (and trust levels). This is really a non-trivial problem, because not all of it can be reasonably automated, leading to a false sense of security. To be clear: checksum checking is NOT a security feature.

I find it hard to believe that people would be more comfortable in using a script they've never heard of maintained by a much smaller set of people over something that I am pretty sure has a much larger order of magnitude of users and trust.

I think most people have never heard of chocolatey either. ghcup has been reasonably well covered on haskell IRC and is regularly used by non-haskellers (because tidal now recommends it as part of the install process). And haskell-platform also recommends it.

With this growing interest in ghcup, the requests for Windows support have in fact increased,suggesting many people haven't heard of chocolatey before.

Given your disinterest in ghcup, I'm not sure if there is anything to draw from this discussion, except that you might want to increase your coverage to make more people aware of chocolatey (which I think is a good thing, making users aware of options).

@Woody88 have you tried chocolatey? Does it do what you want? I'm still open to a Windows port of ghcup, but it seems it might be more work than you thought?

I think most people have never heard of chocolatey either.

I believe this to be wrong; I doubt anyone who works on windows or macOS has head of chocolatey much. Of course windows software development (outside of maybe cross compiling something) is pretty alien to most linux native developers. Talk to people who develop on windows (or even just users) and they usually will have heard of chocolatey.

Now why hasn't this been more public that we have had ghc releases including cabal, and the tooling around it for a while? Well the ghc download instruction website is a pretty contentious thing to change. I'm not going to name names here or go into detail much. Let's just say that there are different fractions int he community that prefer different methods of installation. The page on the other hand should ideally be un-biased, but bias is always suspected. Hooray! The end result is that even though we have chocolatey as an install path, for now changing the official download instructions is a non starter as it insures too much discussion/blame/...

Let's be honest about this, for most people working and developing with haskell, windows is just not a primary platform that is being looked at.

Now, I'm not opposed to anyone making ghcup work on windows as well, everyone is free to spend their time on whatever their passion is. However dismissing chocolatey as something unheard of is akin to claiming homebrew is unheard of on macOS. Both I believe to be wrong; again only from my person interaction with people who develop on windows (or use windows) or macOS.

However dismissing chocolatey as something unheard of is akin to claiming homebrew is unheard of on macOS. Both I believe to be wrong; again only from my person interaction with people who develop on windows (or use windows) or macOS.

Well, I think we can establish that such claims are generally anecdotal (whether ghcup, chocolatey or homebrew is unheard of).

I was referring to my experience in #haskell IRC, what I read on reddit and so on. I don't know many developers using Windows. But I've never seen chocolatey being discussed, nor recommended there. Either that is an indication that the user base is just too small or that it's not advertised well enough.

Since I don't think it makes sense for ghcup to advertise chocolatey, the question remains whether a ghcup windows port is really what windows users need/want. I haven't seen any compelling argument for or against it, so I don't have an opinion.

I made rough-cut ghcup for PowerShell. https://github.com/kakkun61/ghcups

Interesting results from the haskell survey: https://taylor.fausak.me/2019/11/16/haskell-survey-results/

9% of overall participants use ghcup
1% of windows participants use chocolatey (it wasn't an explicit option though, so might not be truly reflective of the situation)

I suggested in the reddit thread to add chocolatey as an explicit option for the next survey and make this choice platform-specific, because it's hard to analyze it correctly due to multiple-choice.

closed via commit b69ae298

mentioned in issue ghc/ghc#18104

mentioned in issue ghcup-hs#130 (closed)

Windows Support

Child items ...

Activity