I'll give my perspective below. Not being intimately familiar with the
Platform's Windows packaging effort, some of this may not be spot-on.
However, I do think I have some context that
lennart spitzner
On 25/04/2020 11:20, lonetiger@gmail.com wrote:
Yes, this was changed recently as it provides a way to manage all 3 components individually. As in should you want to you can have any number of versions of GHC installed at the same time.
By decoupling the components it allows for quicker updates and releases and for a better user experience. Platform was for instance still using GHC 8.6.5 and cabal 3.0.
For the record these packages aren’t new, they’re only now being recommended.
[snip] Having looked at the Chocolatey installation instructions, I will agree that they are a bit rough, particularly in the case of a user without administrative access. However, the benefits of piggy-backing on Chocolatey seem significant: * having worked on projects which were locked to a particular GHC version, I can attest that multiple side-by-side compilers is a need that many industrial users certainly have. * our previous Windows installer infrastructure [1] is essentially unmaintained. It would take time and effort on the part of someone to bring it into a working state. Moreover, even when it "worked" it had serious issues (%PATH% issues were a constant headache, the msys installation could be easily broken by the user), was not built on the MSI installer subsystem officially sanctioned by Microsoft, and imposed a significant maintenance overhead (building a functional distribution required no small amount of luck) * the Windows developer community seems to have largely consolidated around nuGet and Chocolatey; following this trend seems wise given how tricky (proper) packaging for Windows tends to be My sense is that Chocolatey is the right approach here. We simply need to make it more accessible. After a long discussion with Tamar, I think we have a plan that could move us in this direction. I have documented this plan in #18104 [2]. While it's possible that Tamar or I could get to working on this eventually, it would be much better if we could get help from the broader community since there is little GHC-specific knowledge necessary. In general we have precious few developer-hours looking at GHC Windows issues; it would be a shame to have to spend them on packaging issues. If you are interesting in contributing please comment on the ticket. Cheers, - Ben [1] https://github.com/haskell/haskell-platform/blob/master/windows-platform.sh [2] https://gitlab.haskell.org/ghc/ghc/issues/18104