on windows, stack paths only installed per user

[gbaz]

As per https://www.reddit.com/r/haskell/comments/5t6ggy/installation_of_haskell_platform_in_windows_10/

Note that this only becomes apparent as an issue when the platform is installed with a distinct systemwide admin account from the user account. The reported issue says "I followed the recommendation of running the installer with Administrator privilege." -- I'm not sure where this recommendation occurs? But certainly if a user has a two account setup then this can cause oddities.

Not sure of the right approach -- we could certainly set STACK_ROOT ourselves systemwide (though, its not clear to me, if on a pc where the user account doesn't have admin rights, that a top-level stack_root is necessarily even writable by the end user)?

Arguably, it would be nice if the stack installer just had a "systemwide" flag it could be called with. Alternately, the HP installer could let the user choose which "profile" to install stack into, I guess?

[gbaz]

(As usual, an acceptable minimal solution could just be to document the oddities better so users who read the instructions at least aren't confused by them...)

[randen]

We added a switch to the HP installer, "/STACK=" for setting the install directory for stack, since there seemed to be no other way (at the time; maybe it's changed by now?). True, the /STACK switch requires the user to know that stack will be installed in the wrong place when run as the admin.

By the way, this all works as expected in a typical, single user Windows installation. That single user is typically in the admin group, the HP installer elevates priviledges when needed (relying on the NSIS installer to do that), paths are still relative to that single user, and stack installs (no elevation needed) as expected.

If the user is not in the admin group (or otherwise has no admin priviledges), then the install into the default %PROGRAMFILES% would fail, so the HP installer checks privileges first, providing a warning/recommendation to the user. Following the recommendation, the user launches the HP installer as an admin (e.g., via the right-click menu "Run as administrator"), then we get the behavior decribed in this issue.

So, there is a general problem that running the HP installer from one account doesn't let you install it for another account. I believe the MS installer handles these situations using "advertised installations" but I am not sure that the NSIS installer can do this.