Windows installer

[conklech]

I've made a simple Windows installer using the nsis package. The source is available at conklech/stack-installer, and I've made a preliminary binary release packaging 32-bit stack version 0.1.2.0. I've tested it on my Windows 8.1 machine, but that's about it.

To make an actual installer from the source code, you need to compile and run the Haskell program, which will generate an NSIS script that must in turn be compiled. I used the unicode NSIS compiler available at http://www.scratchpaper.com/. If using a non-unicode version, be sure to use a "long strings" build to avoid corrupting the user's %PATH%. The .nsi script expects stack.exe to be in the same directory.

If it's useful, I'd prefer that it get merged into the stack or commercialhaskell project. I can't commit to maintaining it or making updated builds. Because stack is self-upgrading, having a cutting-edge installer is helpful but not critical.

The main shortcoming at the moment is related to #133: the uninstaller does not remove cached build artifacts or compilers installed by stack. (This makes the uninstaller slightly pointless; its main function is to restore the user %PATH%.) I think that functionality should be built into stack; perhaps the installer can optionally run stack rm.

[radix]

@conklech speaking of self-upgrading, have you ensured that if a user does stack upgrade that the new version will replace (or at least take precedence over) the one installed with your installer? I don't have a windows machine to test on at the moment, I just thought I'd ask since this is a pretty important case to handle.

[conklech]

@radix - I allow the user to choose where to install stack, but the default follows the suggestion on the Downloads page to install to %APPDATA%\local\bin. By default, that path is also added to %PATH%. I believe the \local\bin path is hardcoded into stack at the moment. I believe stack installs all binaries, including stack itself, into \local\bin.

In the default case, stack should upgrade itself properly without any precedence problems. In the non-default case, stack upgrade won't work properly, and neither will stack install, because the \local\bin location is not on the path.

I could make the installation location non-customizable, but that feels somehow wrong. It might also be possible to add some documentation to the installer. (I don't know; nsis is a little bit inscrutable, particularly when the actual NSIS documentation is on a server that's broken, as sourceforge.net is at the moment.)

[radix]

@conklech that sounds good. A message describing this would be nice but I have indeed heard that NSIS is pretty difficult to use so I don't blame you :)

[borsboom]

Very cool.

Regarding uninstallation, I think all it should have to do to remove the "cached build artifacts or compilers" is delete the whole stack root directory (~/.stack on Un*x, I forget where it goes on Windows and don't have my VM booted right now), since that's the only place stack writes anything outside of projects and executables in local/bin. That could probably just be done by the uninstaller itself (although the hardest part of adding it to stack would be choosing a name for the subcommand). It would be nice if deleting the stack root were optional (e.g., a checkbox in the uninstaller).

I am definitely happy to merge this installer into stack's release process.

[conklech]

The main reason I didn't just delete %APPDATA%\stack is that it potentially contains non-regenerable user configuration data, i.e. global/stack.yaml. That plus a general policy against running the equivalent of rm -r on other people's machines unless I'm damn sure I know what I'm doing.

And, as discussed a little bit on the other issue, we're going to need a non-uninstallation mechanism of cleaning out the stack directory anyway, as users start accumulating outdated lts and nightly snapshots.

[borsboom]

Ok, what you say makes sense. Until there is a stack gc command (or whatever it ends up being called), I think at least showing the user a message at uninstallation time telling them they can delete the stack root (and get back a good bit of disk space) would be good. Or perhaps even better, a prompt (with no default) to offer to do so for them.

[conklech]

I've pushed an update to include uninstaller options to delete %APPDATA%\stack and %LOCALAPPDATA%\Programs\stack. I've not tested and I'm not 100% convinced it's safe, so I haven't updated the binary installer.

I could add extra warning prompts, but nsis can't create prompts with no default option, and I don't think the default can be changed from "yes."

[borsboom]

Would it be possible to have this installer be "thin" and actually download the latest stack executable from the Github release, rather than include the executable with the installer itself? That way we wouldn't need to update the installer with every release.

[conklech]

Possible, but with additional infrastructure work. Sourceforge is still (!) down, so there's no NSIS documentation without trawling through Google caches, but stackoverflow suggests there's at least one plugin out there to do something along these lines. The Haskell bindings would need to be updated to include it.

I think #532 would be a pre-requisite for that feature.

[3noch]

You could probably write a tiny exe to download stack and just run it during install. Of course, you could also package up something like wget and use it instead or embed a PowerShell script to do it (but you might be limited to certain Windows versions).

[ndmitchell]

Updating the Haskell nsis to wrap the http lib is no problem at all - just raise an nsis ticket and I'll do it if you want. Having stack gc sounds like an excellent plan, I too get very scared by uninstalling.

[3noch]

Might be nice to have HTTPS and/or hash verification. Last I checked the nsis plugin did not support those? Maybe it doesn't matter for this case.

[ndmitchell]

Wouldn't it be better to install a slightly old version then stack upgrade after install? That way stack can have all the verification junk.

[conklech]

That was my idea: let the user upgrade as needed, to avoid duplicating
upgrade systems.
On Sep 11, 2015 11:02 AM, "Neil Mitchell" [email protected] wrote:

Wouldn't it be better to install a slightly old version then stack upgrade
after install? That way stack can have all the verification junk.

—
Reply to this email directly or view it on GitHub
#613 (comment)
.

[borsboom]

@conklech: I've started work on building this into the stack release process now. In testing today on Windows 10, only one problem I've noticed: In Settings -> System -> Apps & features (formerly the Add or Remove Programs control panel), selecting stack and choosing Uninstall doesn't seem to do anything (it doesn't launch uninstall-stack.exe).

[conklech]

@borsboom: Could you check that the Registry key HKCU/Software/Microsoft/Windows/CurrentVersion/Uninstall/stack is correctly populated with the path to the uninstaller?

[borsboom]

Thanks, fixing that did the trick. I've uploaded experimental installers to the v0.1.6.0 release:

• Windows 32-bit Installer
• Windows 64-bit Installer

Please download them and give them a try.

[borsboom]

Has anyone had a chance to try the Windows installers?

[ndmitchell]

Just tried it. Worked nicely for me.

[radix]

I used the 64 bit installer a week or two ago on my Windows 10 machine. Worked without a hitch.