[haskell-platform] #6: Windows installer

haskell-platform haskell-platform at projects.haskell.org
Thu Apr 23 06:33:15 EDT 2009

#6: Windows installer
 Reporter:  duncan    |        Owner:  refold             
     Type:  task      |       Status:  reopened           
 Priority:  major     |    Milestone:  Release 1: 2009.0.0
Component:  Platform  |   Resolution:                     
 Keywords:            |  
Comment (by claus):

 Nice to see that someone has taken on this task! Haven't tested, sorry
 (narrowband limitations meaning that I build my own ghcs and only download
 installers once the bugs have settled, in ghc-X.3 or so;-), but I'd like
 to offer some comments:

  - uninstall is absolutely essential for installers, and it needs to be
 complete (uninstall every change it made) and precise (not uninstall
 anything it can't recreate). I put this first, because installers seem
 difficult to get right, so it is important to be able to undo whatever
 they do, without making an even greater mess because the uninstall isn't

  - windows installers for ghc and hugs have a long history of issues, some
 of which are documented on the ghc trac. Browsing closed tickets for
 things that have gone wrong in the past will give you a good idea of what
 to avoid (such as incomplete `GLUT` provisions, changing filetypes, not
 preserving existing filetype actions, etc), and there are still some open
 tickets. Many tickets are about bad defaults, missing user options,
 overwriting existing user preferences, not playing nice with other haskell
 installers (hugs and ghc installers used to change each others filetype
 settings, and similar fun).



     - [http://haskell.org/haskellwiki/Installers]

  - the issues tend to vary, but there have always been some issues in the
 past, so I have preferred just to unpack the archives from the nightly
 builds whenever possible. It would be good to have a "just unpack files
 where I tell you to, don't change registry,PATH, or anything else" option
 for the HP installer, for users who have been burned as often as some of
 us have been, or just to keep the downloaded installer useable if there is
 a minor issue with it.

  - everything an installer does needs to be optional, as preferences and
 configurations differ widely (the just-the-files-please option above is a
 useful fallback if you don't want endless option dialogues)

  - one issue is that installer authors tried to make "nicer, more
 sensible" choices, which of course differed between authors, didn't match
 user preferences, and worst of all, weren't constant, so couldn't be
 relied on - please avoid that!-)

  - installers don't live in isolation! Other Haskell programs want to use
 the same files, with hopefully the same filetypes/associations linked to
 the same endings. Users want to add other actions to those filetypes (I
 regularly have at least one editor, several ghci versions, and one winhugs
 version linked to that filetype, and my default action is edit, not one of
 the interpreters!). It has been surprisingly common for installers to mess
 up and void my existing settings (either they clear out the existing
 actions, or they associate the ending with a different filetype

  - using a path with spaces as the default would not be a good idea: I
 have often cabal installed things like haddock, happy, .., only to find
 that they end up in a location that the ghc build system can't handle, so
 I have to edit the default, remove the install (`cabal uninstall`,
 anyone?), and install again.

  - my current layout usually has several ghc versions coexisting with
 their own set of packages, but with a shared set of tools
   I would have liked all of cabal there as well, but by the time I ran
 into the tools-in-paths-with-spaces issue, it had installed all kinds of
 stuff in `c:/Program Files/Haskell`, and I never got round to cleaning
 that up (`cabal uninstall`, anyone?)

  - `ghc-paths` is the first package I install for each ghc build, but it
 needs to be installed after ghc build/install to get the right paths.

  - after a while, no matter how large it seems after purchase, the `c:`
 drive is getting full, impeding normal system operation; so, many users
 will want to be able to move cabal and its packages to another drive to
 make space on `c:`, even if their preference would have been to keep the
 packages with the compilers.

  - how are you going to make sure that the HP installer's cabal packages
 match existing cabal settings on the system? Or is there going to be a
 separate cabal install for each HP, each with its own config files and

 Hope this helps, and thanks again for taking this on.

Ticket URL: <http://trac.haskell.org/haskell-platform/ticket/6#comment:12>
haskell-platform <http://trac.haskell.org/haskell-platform>
The Haskell Platform: a comprehensive and robust collection of Haskell libraries

More information about the Haskell-platform mailing list