New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows installer #613

Closed
conklech opened this Issue Jul 16, 2015 · 20 comments

Comments

Projects
None yet
5 participants
@conklech

conklech commented Jul 16, 2015

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

This comment has been minimized.

Contributor

radix commented Jul 16, 2015

@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

This comment has been minimized.

conklech commented Jul 16, 2015

@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

This comment has been minimized.

Contributor

radix commented Jul 16, 2015

@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

This comment has been minimized.

Contributor

borsboom commented Jul 17, 2015

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

This comment has been minimized.

conklech commented Jul 17, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 17, 2015

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

This comment has been minimized.

conklech commented Jul 17, 2015

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 borsboom added this to the 0.2.0.0 milestone Jul 21, 2015

@borsboom borsboom assigned borsboom and unassigned borsboom Jul 21, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 21, 2015

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

This comment has been minimized.

conklech commented Jul 21, 2015

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.

@borsboom borsboom modified the milestones: 0.3.0.0, 0.2.0.0 Jul 21, 2015

@borsboom borsboom self-assigned this Jul 29, 2015

@3noch

This comment has been minimized.

Member

3noch commented Sep 10, 2015

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

This comment has been minimized.

Contributor

ndmitchell commented Sep 11, 2015

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

This comment has been minimized.

Member

3noch commented Sep 11, 2015

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

This comment has been minimized.

Contributor

ndmitchell commented Sep 11, 2015

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

This comment has been minimized.

conklech commented Sep 11, 2015

That was my idea: let the user upgrade as needed, to avoid duplicating
upgrade systems.
On Sep 11, 2015 11:02 AM, "Neil Mitchell" notifications@github.com 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

This comment has been minimized.

Contributor

borsboom commented Oct 15, 2015

@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

This comment has been minimized.

conklech commented Oct 16, 2015

@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

This comment has been minimized.

Contributor

borsboom commented Oct 16, 2015

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

Please download them and give them a try.

borsboom added a commit that referenced this issue Oct 17, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 26, 2015

Has anyone had a chance to try the Windows installers?

@ndmitchell

This comment has been minimized.

Contributor

ndmitchell commented Oct 26, 2015

Just tried it. Worked nicely for me.

@radix

This comment has been minimized.

Contributor

radix commented Oct 26, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment