Windows installer

[duncan]

We need someone to take charge of building and testing the Windows installer.

It should include everything in a single installer. Users should not have to get ghc first. It's probably sensible to use the same installer technology as GHC uses. We can start from the generic binary builds that GHC HQ build.

[refold]

I can start working on this when I'm done with the exams (after April 17). In the meantime, if someone can prepare the installer faster, feel free to take this task.

[refold]

I started working on this; will roll out the beta installer soon. The first version will be a simplistic NSIS-based installer, embellishments will have to wait until the next release.

[dons]

Notes from Sigbjorn Finne on how Bamse can be used:

Bamse could fairly easily produce an MSI from the list below (the platform spec), with one or
more of them being included as MSI components within it (e.g., GHC,Happy).
That is _provided_ the individual packages are self-contained; on
Windows that isn't the case for a couple of them (zlib,OpenGL,...),
so presumably the relevant DLLs will have to be included also.
There's bound to be some manual work here..

Once we work out what tools to use, please document them here: http://trac.haskell.org/haskell-platform/wiki/Windows

[refold]

I'll go with NSIS for now, but will consider using Bamse at some point in the future.

[refold]

I'm about 75% done, just have to figure out how to make configuration templates work (examples on NSIS wiki are buggy).

[refold]

Status update: the installer is mostly complete, I will put it up for testing as soon as I get a code.haskell.org account. Source code's at http://github.com/23Skidoo/haskell-platform-windows/ .

[duncan]

Yay! It works :-)

Feedback on current installer:

• Does it need to ask for two independent dirs during installation? One for ghc and one for everything else. Can't we just ask for a single location and install everything (including ghc) under that?

• If we used a single install tree then there would be a nicer layout rather than two doc dirs, to bin dirs etc.

• We should not install ghc-paths. In any case the paths are wrong because they refer to the paths on the build machine not the target machine. Haddock is currently bundled as part of ghc so it does not need to be included again. Then ghc-paths is not needed either.

• Perhaps the programs (start menu) group should default to Haskell rather than GHC?

[refold]

Can't we just ask for a single location and install everything (including ghc) under that?

Ok, I'll use Program Files\Haskell and install GHC to Program Files\Haskell\GHC\ghc-$VERSION.

If we used a single install tree then there would be a nicer layout rather than two doc dirs, to bin dirs etc.

I think it is cleaner to use separate dirs. For example, if the user wants to use both GHC 6.8 and 6.10, she can install 6.8 to Program Files\Haskell\GHC\ghc-6.8.

(Hmm, I just thought about what happens if we want to install two versions of the Haskell Platform... Perhaps it's better to use Program Files\Haskell Platform\2009.0.0 and do not touch Program Files\Haskell)

We should not install ghc-paths.

Ok.

Perhaps the programs (start menu) group should default to Haskell rather than GHC?

Or Haskell Platform\2009.0.0, as Bulat suggested. The current behaviour is consistent with the GHC installer.

[bulatz]

1. I think that we should allow different HP versions to coexist. actually, each HP is just bundle of some ghc and library versions, so i HP 2009 installs ghc 6.10.2 + gtk2hs 0.10 and then HP 2010 installs ghc 6.12 and gtk2hs 0.11 - everything should be ok. the only problem is installing of the same ghc/library versions - it shou;ldn't overwrite previopus user data, such as ghc-pkg config

it will allow users to run apps developed with various Рзы in mind without reinstalling HPs all the day

2. ithink that we should go at the way of simplifying and making more natural choice of install directories and Start Menu paths - rather than following existing GhC habits, we would ask GHC team to change them

so, everything should be installed under "Program Files\Haskell" directory, into ghc-6.10.2, fgl-0.3.1 and so on subdirs and every HP should install into the same directory - as far as we can solve above-mentioned overwrite problem

we should then create "Start menu\Haskell\Ghc-6.10.2" submenu

and we should recommend GHC developers to install to the same dir/menu, and other Haskell infrastructiure developers to use the same Haskell dir/menu

3. another possible alternative is that we consider each HP version as independent and install into "Program Files\Haskell Platform\2009.0.0" directory with menu at "Start menu\Haskell Platform\2009.0.0\Ghc-6.10.2"

[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 precise.

• 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://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Einstaller&summary=%7Eregistry&summary=%7Einstallation&os=Windows&os=Unknown%2FMultiple&order=priority

• http://hackage.haskell.org/trac/ghc/search?ticket=on&wiki=on&q=installer&noquickjump=1&page=5

• 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 alltogether).

• 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

  c:/ghc/
    ghc-<version1>/
    ..
    ghc-<versionN>/
    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 preferences?

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

[anonymous]

Replying to claus: Thanks for the detailed comments, this is all very interesting! I think I'll have to open several separate tickets based on your feedback:-)

[refold]

Replying to anonymous:

Replying to claus:

That was me, forgot to log in.

[refold]

I think that we can close this ticket now; any issues related to the Windows installer should be discussed in separate tickets.