Windows installer -- stack may not install if %APPDATA% resolves to an active directory UNC path

[gbaz]

Arguably, since this is where the stack executable lands, it should be added. On the other hand, our installation of stack follows the lead of the stack installer, which doesn't add it. Nonetheless, probably safe and better to do so, as this is in keeping with the service the installer provides for GHC, etc.

[jmchapman]

I think that this part of the install failed for me. I don't even have the directory. I suspect it might be that my %APPDATA% resolves to an active directory UNC path. Has this been tested? Should I raise a separate ticket for this?

I will struggle to test as this happened on a locked down desktop where I don't have admin permissions and I had to ask somebody to install the platform in the first place.

[gbaz]

The platform installer for windows wraps the stack installer for windows, so it may be that the issue fails there too :-/

https://docs.haskellstack.org/en/stable/install_and_upgrade/#installer

Sorry I don't have more insight into how to figure this out.

That said, if you just need stack, you can probably drop the binary from here https://docs.haskellstack.org/en/stable/install_and_upgrade/#manual-download anywhere on your system and add it to your path without the installer rigamarole.

[randen]

Since we bundle and launch the stack installer, and if it needs some PATH or registry entries handled, I would expect that the stack installer would do this. The stack installer even has a UI option "Add to user %PATH%" that is 'on' by default.

So, I think the stack installer is doing this.

Edit: I have just installed/uninstalled via HaskellPlatform-8.0.1-minimal-x86_64-setup-a.exe two times in Windows 7, leaving everything in the UI default, and the PATH does seem to be correctly updated to include the stack portion (and done by the stack installer). My test scenario might be different from yours, however. You might need to launch a new CMD.EXE to see the changed PATH but you should be able to see it immediately in the "Control Panel > System > Advanced system settings > Environment Variables".

Edit 2: [was writing my comment while the above comments were coming in.] In my scenario, I do have APPDATA resolved to my local machine (my home, self-administered PC). Also, for this scenario, we bundled stack 1.1.2.

[gbaz]

Thanks randy, sorry for the noise in my jumping to the wrong conclusion. I'll update the title accordingly and I guess leave this open for now, even though I guess the issue is more with the upstream stack installer.

[gbaz]

related: https://github.com/commercialhaskell/stack/issues/2548

[gbaz]

@randen continuing the purely HP side of the discussion from the "related" ticket here -- I agree that for a full "enterprise install" situation we may want to consider MSI again (from what little I know). But for the circumstance presented, I think just moving the windows story to bundle the stack binary directly as it does other binaries should be fine, and at least address a case such as is here. This won't affect paths for all users, so e.g. if an administrator installs software as an admin, then the local path won't get fixed for "stack upgrade". But we can just add that to our "additional instructions" and its certainly a step forward.

[gbaz]

Doing that change (moving away from bundling stack installer) would also fix #248 I think

[randen]

One of the reasons to bundle the stack installer rather than the stack executable was this kept all decisions of stack to stack. For example, if the stack installer detects it is already installed, it might do something different; if HP puts stack into the same place as where we put, say, cabal.exe, the user upgrading stack later might not get the same location of stack.exe updated. Now, they might not get the stack they just installed! (this kind of thing has bit users before with cabal.exe, and probably still is a problem, in fact).

Also, in the current behaviour of HP installing stack (not the one in this issue, though), upgrades to stack do not require the user to be an admin, since the files are going to a user-specific location. If HP installs stack.exe, upgrading requires being an admin. Also, with a proper "pure" (e.g., enterprise-worthy) installer, an installer should never uninstall something it did not install (and this might be enforced by the installer logic by comparing file paths and sizes; also if, e.g., stack v17 includes more files, those might become orphaned; also, uninstalling could yield errors at uninstall time as now there could be two installers registered with Windows to uninstall one file). So, to allow basically corrupting a correct installation by swapping out a file, would not be a thing an MSI installation engineer would want to advocate, I don't believe (but, again, I am not really an installation engineer).

Generally, I do not think you want to allow a possibly separately-installable component to be included in an installer in such a way that this separability is not by design. Installing stack using the stack installer recognizes this separability currently.

Putting stack.exe some place that the stack installer might not expect to find it should, in a perfect world, require that the stack installer and the HP installer coordinate "who's got the stack.exe".

Now, back to this particular issue. I would need to understand (i.e., go read up on) the cases where APPDATA is not defined or is defined as a network path. There might be some other behavior that an application or installer are "supposed" to take in such situations, based on best practices, technical requirements, etc.. Off the top my head, I do not know the answer. I am not so savvy on current enterprise-level Windows installation approaches, best practices, etc.. (Hmm, maybe stack should be/meant to be using "AppData\local" rather than %APPDATA%\local which resolves to "AppData\Roaming\local"? Just a thought I can investigate. Wondering aloud: in an enterprise desktop, is AppData\local actually local on the user's machine?)

[gbaz]

My understanding on this particular issue is I think a bit simpler, and maybe too simple. I imagine that the administrator installed the software from an administrator account. So the stack binary maybe did get installed? But to the AppData of the administrator account instead of the AppData of the user's account? Meanwhile, since ghc and soforth get installed to a systemwide location, they still wind up in an appropriate place...

[gbaz]

(btw, thanks for the clarification on the larger discussion on issues with installers -- you may disclaim being an installation engineer, but you certainly know these issues better than I do!)

[lorengordon]

@randen, %APPDATA% always refers to the <user>\AppData\Roaming location. This location is intended for permanent, per-user application files and data and may be redirected using a Windows policy to a network share. Redirecting to a network share makes it is accessible to the user across different machines without needing to be copied to each machine. This would be the typical install location for a per-user install. No admin privileges are required to install to this location.

%LOCALAPPDATA% always refers to the <user>\AppData\Local location. This location is meant to be used for mostly temporary application data, such as caches that the application can regenerate on demand. It may follow the user from machine to machine if the user also has a roaming profile, which copies the user profile from a network share to the local machine upon login (and back upon logout). It would be very unusual to install an application to this location.

%PROGRAMFILES% (or %PROGRAMFILES(x86)% for a 32-bit app installing on a 64-bit machine) is the typical install location for a machine-wide install, which would be accessible to all users of the machine. This location requires admin privileges to install, but not to access the files. A GPO-based MSI install would typically use this type of install. It's common for these machine-wide installs to also update the PATH environment with the location of the application binaries.

fyi, I ended up here looking for that last option, a machine-wide install of HP, to include tools such as cabal which seems to end up in %APPDATA%\cabal using the current installer, even though HP is installed under %PROGRAMFILES%\Haskell Platform.

[lorengordon]

Ahh, ok, turns out cabal.exe is in the correct location, it was a package installed by cabal that ended up in %APPDATA%\cabal\. That finding led me to the --global option for cabal install, which put the package in %PROGRAMFILES%\Haskell\bin, which is in the PATH. Ok, with that, I think I can make the current installer work for my needs, long as I can get a scripted, silent install of HP.