HP 8.0.1 minimal Windows install installs HP system-wide and stack per-user

[jmchapman]

Our admin has installed the HP 8.0.1 minimal install on my windows 10 machine. I understand that the HP installer calls the stack installer to install stack.

Stack is nowhere to be seen. The installation otherwise seems to work: cabal, ghc, cabal-installed executables are in my path, I was able to build agda.

I don't have a directory at %APPDATA%/local/bin.

My %APPDATA% is on a network drive at \ds.blah...\myusername

I wonder if this scenario (essentially an enterprise environment) has not been tested?

[Blaisorblade]

• Do you have a chance to run the stack installer directly? I think it doesn't require admin rights.
• However, there might be an auto-enabled item setting STACK_ROOT to C:\sr (long-standing TODO I did, Set STACK_ROOT to C:\sr by default borsboom/stack-installer#1). If you can't write in that directory (as I fear—can you test?), that won't work. Still, this wasn't there in the 1.1.2 installer, you should be able to disable it. Either way, stack should be created in %APPDATA%/local/bin.

I understand that the HP installer calls the stack installer to install stack.

Do we have a chance to confirm that?

TODO for the Windows installer (ping @borsboom):

• Don't autoset STACK_ROOT to C:\sr if the user can't write there.
  Does this affect the release of 1.2.0? You can work it around but that's not the experience we want.

[gbaz]

I can confirm that's what the HP installer does.

[Blaisorblade]

@jmchapman @gbaz Where are cabal/ghc/... installed? Are they in a system folder? Because stack installs everything per user, hence probably the admin installed stack on his account. I'm guessing the HP is or can be installed system-wide?

Proposed workaround for now for @jmchapman: run the stack installer. Do you have a chance to (ask the admin) to inspect his home? (I assume not, still asking).

Regarding solutions: stack is installed per-user so that they can overwrite the binary when upgrading.

Nevertheless, Windows admins won't install stack per each user. And in a Windows network having each user install stack can be... inconvenient.

If we want to allow Windows-wide installs, we might want to try mirroring Unix's setup:

• install stack system-wide and it to the PATH
• add each users' %APPDATA%/local/bin to that user's PATH (hopefully at once) so that upgrades are still supported. I'm not sure that works as easily, but it's worth a try.

[gbaz]

Yes, the platform goes in Program Files/Haskell Platform/%version% by default. Can we pass an alternate path into the stack-installer so we could just override and make it system-wide by default too?

Alternately, if we make sure we get the things the stack installer does right, we could just replicate it in the platform installer rather than wrapping it. We chose to wrap it because we wanted to do our best to make sure we got the correct defaults. But as it turns out, if we're targeting two different use-cases, it seems fine to me to do it on a distinct codepath, as long as we coordinate well.

[Blaisorblade]

The stack installer generator is here: https://github.com/borsboom/stack-installer/blob/master/Main.hs, so it's not so much code; but the pipeline behind it is pretty scary.

Also, everything is done to make the installation per user—including every mention of HKCU there. In principle a system-wide installation is a rather different path to validate—I can anticipate potential issues:

• spaces (!)
• as mentioned, allowing the stack binary to be upgraded by plain users is pretty important.

I'm not sure what to recommend there.

[gbaz]

Ok, so from the platform perspective, if we A) drop the binary in a global location, B) add the correct elements to the path, and C) I guess set sr (though that's controversial)? then that would be roughly as good (though different in behavior) than using the stack-team built installers?

If so, that seems reasonable from my standpoint (@randen may have other thoughts).

[Blaisorblade]

As long as (B) includes for each user the correct %APPDATA%/local/bin, I don't see yet a problem. Again, I won't guess that works without issues. Our integration test suite might be a starting point if it works with installed binaries. (And I don't think its coverage is 100%, but it's quite something).

Maybe @borsboom has some insight on the stack side?

Regarding (C): setting STACK_ROOT has long been left to the user till #2468. I'm not sure what's safest.

[randen]

This is probably one of those places where we should stop and re-assess the requirements to make sure where we are headed, since it seems like a camel is poking his nose into the tent. The current installer base for both HP and stack is the open-source NSIS. It is not exactly enterprise-savvy (I'm not knocking it, just stating it), as it seems more suitable to single-user type of installs (more like an XP kind of world). I'm sure folks have done lots with NSIS, including enterprise deployments but, out of the box, it is missing many features, and those folks would have had to implement such additional features.

To comfortably support enterprise-worthy installations, with proper support for Windows 10, "advertised" installs, patches, transactional behavior (e.g., if our NSIS installers fail, the installation is just left half baked), signing, etc., this would be the time to talk abouit switching from NSIS to the Microsoft Installer (MSI files). I am not at all an expert in the Microsoft Installer technology (nor in the NSIS platform, either!), so take what I say with the proper caveats.

[lehtoj]

Standard user accounts do not have write permissions to Program Files, but they can create new directories under root of system drive, e.g C:\sr or C:\stack_root. However, it is entirely possible enterprise workstations do have additional restrictions that prevent standard users from creating new directories under root of system drive.

Even in enterprise settings standard user does have write permissions to their own user profile, which includes APPDATA.

It is fine if Stack keeps the current directory setup of C:\sr or C:\stack_root, because under normal conditions user can write to those directories. For the cases where they cannot, Stack installers simply should provide option to provide alternative path.

As far as paths go, only %APPDATA%\local\bin should be fixed. Under usual circumstances, the path translates to C:\Users\username\AppData\Roaming\local\bin. It really should be C:\Users\username\AppData\Local\Stack\bin, which would then be %LOCALAPPDATA%\Stack\bin. It may even be worth consideration to use %LOCALAPPDATA%\Stack\root instead of C:\sr or C:\stack_root, even if it does increase chances of hitting character limits in path length.

Microsoft is working on removing these archaic path length limits. Windows 10 Anniversary Edition already has some preliminary support for long paths, the one major piece that is still missing is long path support in command prompt, but that is coming. Once long path support becomes mature enough, it should become enabled by default. See this blog post for details. Unfortunately this information does not help folks stuck with older Windows versions.

Roaming appdata is meant for data that "roams" in a domain to any computer the user uses. This is useful for storing application settings and the like, where files remain small and few. On the other hand, Local appdata is for files that stay on the local computer, for example application binaries.

User environment variables can also be set without admin privileges, so this shouldn't be a problem either.

[Blaisorblade]

@randen Since you have more insight than me on this, can a system-wide installer prepend %APPDATA%/local/bin to %PATH% for all users? Right now that seems the key technical question.

No strong feelings re MSI vs NSIS. Our installer was born in #613, and the Haskell binding for NSIS might have been the biggest argument (after my limited experience, writing NSIS scripts directly seems a bad idea).

[snoyberg]

Just to sum up my understanding/memory of the trade-offs for system-wide vs user installation of Stack, what our Windows installer does, and recommendation for the HP installer:

System wide requires admin permissions, which can be a problem. When just installing the stack.exe executable, there's no much space saved by sharing the installation across multiple users. And the most common use case I'm aware of these days is a single-user system.

Stack's Windows installer therefore:

• Installs stack.exe to APPDATA\local\bin
• Adds that dir to the PATH for that user

Stack itself is then responsible for installing and finding all other executables (GHC, MSYS), and can be upgraded by replacing the stack.exe in APPDATA\local\bin (via stack upgrade).

The problem with just using the user-local installer together with HP's system-wide installer is broken assumptions: if a user has GHC from the global HP installation, it seems reasonable to assume that Stack will be available too. However, we don't want to lose the ability to do upgrades. Therefore, I recommend for HP to:

• Include stack.exe in a global location, just like cabal.exe is provided
• Add APPDATA\local\bin to the PATH for all users, so that stack upgrade works

The result will be that HP users will have full access to Stack, presumably with no negative impacts. The system-wide GHC installation will not be used by Stack at all (once #2537 is merged), making the HP installer take up more space without benefit for users relying completely on Stack. Also, compared with the Stack installer, the HP installer will require admin permissions, which could be a problem for some users. On the plus side, all users on a system will have immediate access to Stack once it is installed.

[jmchapman]

@Blaisorblade I checked with the admin and indeed stack was installed in his %APPDATA%. Fortunately it was a local account to my machine and didn't pollute his roaming profile. I can't remember if it was installed with him logged in on my machine, or if I was logged in and he approved the privilege elevation during the install, probably the former.

From my point of view it would be nice to be able to install HP and stack without admin permissions so that I don't have to bother anyone to install it/update it.

From the admin point of view it would be good to be able to do one install for all users.

Clearly the current hybrid is not good.

I can report that I was able to run the stack installer without admin privileges, it added something %APPDATA%\local\bin to my path and I am able to run the stack command from the command prompt.

[Blaisorblade]

+💯 to @jmchapman.
And yes, a user-local installer for the HP would make lots of sense and I don't know why I didn't ask that earlier. And hopefully it'd be easy (while we still have one question on the global installer we're discussing)?

In a perfect world, this shouldn't even require a separate download—and the default should probably be a per-user install since most systems are single-user as pointed out.

[snoyberg]

I definitely had conversations way back in the day with Mark about system vs user installation, and I think there was a desire from the HP side to make a system install. I don't know if @gbaz knows if my memory is correct here, or has motivations for it if that's the case.

[gbaz]

I mean obviously there's a case for both ways, which I think @jmchapman has expressed well. When admins use installers to provide systemwide software they often want to do it uniformly across accounts on a range of boxes at once. Systemwide makes sense there. But being able to do things "sans admin" purely in userspace can be nice when possible too. For many windows users as well, a system install is just considered the "standard" way to do things and anything else would just break expectations.

And there have been enterprise settings I've been in for example when userspace was very limited (in one case because it was synced to a very slow share on every login/logout) and dumping even say 1G of extra files there would either be A) not allowed, or B) grind your login/logout to a halt.

So I can't speak for all Mark's motivations. I can certainly say it seems that it would be nice for the installer to provide options both ways (for the HP side), and certainly as James has point out, on the HP side to be uniform.

[23Skidoo]

HP installer used to have a "just unpack" mode for non-admin installations, though I'm not sure whether it's still supported.

[randen]

Here's the thing though: HP installs stack by launching stack's installer. HP needs to pass the "silent" flag if that is requested by the user but all the other defauilts, UI, detecting if already installed, PATH updating if needed, etc. should be handled by the stack installer.

I have more details, background, etc. on this in a comment of an HP issue: haskell/haskell-platform#252 (comment)

For a single-user install of HP (that is, ghc, etc.), in theory the user should be able to use the installer UI to set a user-controlled (i.e., possibly non-admin) location. (This likely doesn't quite work today as probably some other logic in the HP's installer "script" would need to not do anything global, such as write certain registry keys, etc.) For the "just unpack" functionality, I have a vague recollection that was just part of the NSIS installer? If so, it should still be possible.

[aside: here and in some other issues, we, including myself, need to be careful in our use of %APPDATA% vs "AppData" since %APPDATA% == \AppData\Roaming rather than just \AppData ]