Location of stack's config.yaml on Windows

[CMCDragonkai]

According to https://github.com/commercialhaskell/stack/blob/master/doc/yaml_configuration.md there's nothing about the configuration file's location in Windows, in fact most of the docs seem to imply that ~/.stack/config.yaml should also work on Windows. However I found that the configuration file is located here: %APPDATA%\stack\config.yaml. If I create %USERPROFILE%\.stack\config.yaml, will this be read by stack? And if not, why not? GHCI supports reading %USERPROFILE%\.ghci on Windows. I work on both Windows, Cygwin and Linux, and would prefer to have the configuration files in a standardised location (makes my .dotfiles simpler).

[Blaisorblade]

First, it'd be good to fix the docs—a PR would be great!

Second, the location of ~/.stack can be set via STACK_ROOT (which the docs recommend anyway for other reasons). But most of it is data that doesn't belong in dotfiles (though maybe that can be fixed via a .gitignore). I'd maybe take a look at Windows symlinks, even though they can only be created by root?

Third: changing the default location read would be awkward, but adding a new path might be an option if there's sufficient demand for the extra code complexity and testing — though it's not obvious this qualifies. However, %USERPROFILE%\.stack\config.yaml seems a bit inconsistent with other programs. Also, I'm afraid, stack seems to assume all its data is in the same .stack.

About the GHCi behavior: So, I'm not sure why GHCi does that, or which GHC version that is: Is yours, by any chance, a Cygwin-based GHCi? That might make a difference.

Stack uses a somewhat standard Haskell API to determine the location, and its docs specify using %APPDATA% on Windows. I'm not sure that would apply to Cygwin. Also, this is an API for folder locations, not for files...
https://www.stackage.org/haddock/lts-7.0/path-io-1.2.0/Path-IO.html#v:getAppUserDataDir
https://hackage.haskell.org/package/directory-1.3.0.1/docs/System-Directory.html#v:getAppUserDataDirectory

Apparently, a better API for this purpose might be getXdgDirectory, but since ~/.stack mixes config and data it'd be awkward to use.

[CMCDragonkai]

GHCi automatically assumes ~/.ghci as first priority, and only looks at %APPDATA%... for the config if that is not found. That's for Windows and Linux. A cygwin ghci!? (I wish.)

I'm fine with all the data in ~/.stack, I don't see how that's different from putting them into %APPDATA%/stack. Since I would like to have 1 stack config location for both Windows and Linux, that's why I would prefer to have a %USERPROFILE%/.stack, because this matches the same location on Linux which is ~/.stack.

I have to ask though, %APPDATA% is for roaming, and stack has architecture specific compiled binaries there. I would have thought machine specific architecture compiled artifacts should be in %LOCALAPPDATA%.

[Blaisorblade]

Regarding your case: would you be satisfied with STACK_ROOT=%USERPROFILE%/.stack in your dotfiles (which I think would work), or do you have stronger reasons to need default changes?

I'm fine with all the data in ~/.stack, I don't see how that's different from putting them into %APPDATA%/stack.

I have to ask though, %APPDATA% is for roaming, and stack has architecture specific compiled binaries there.

You're right: different parts of ~/.stack would belong in different places. Take a look at XdgDirectory values: the configuration would go in XdgConfig, under %APPDATA%, while the cached binaries would go in XdgCache , under %LOCALAPPDATA%. I agree it'd be nice to fix this, though there's some transition pain to deal with, so adding that part for now to P3 milestone. To prioritize this better: is it actually possible to have cross-architecture roaming profiles? I guess you could across ARM and x64, but that happens seldom nowadays.

Back to the configuration itself: This is a matter of convention and I don't have strong preferences either way, but dotfiles in %USERPROFILE% is just not the native Windows convention, so I guess native Windows users might mind a bit — those files/folders aren't even hidden on Windows.

Nevertheless, if some volunteer (say, you @CMCDragonkai) cares enough to contribute a PR with enough tests I wouldn't mind. What about looking for %USERPROFILE%/.stack before the current location? This way existing users wouldn't be affected, lose their config and so on.

[CMCDragonkai]

So I decided to use STACK_ROOT set as permanent Windows User environment variable. I guess that's the fastest solution right now. (Also by doing this I get a shorter path name! So I guess this goes to working around the path problem on windows).

I'm not entirely understanding what you mean by XdgDirectory and XdgConfig what are you referring to here? I know what XDG means. But not what those variables are.

I guess my request would be that if you do happen to transition to using %LOCALAPPDATA% as well, I would suggest to also add in a prioritised lookup for %USERPROFILE%/.stack first.

[CMCDragonkai]

I just met this problem #1375

Now I hoped I could just do ~/.local/bin for the binaries. But I can't do that, and since environment variables don't work, I can't use $HOME/.local/bin. If I use a Windows absolute path or windows environment variable path, neither will be usable on Linux. The only proper solution is to hope for $ variable support, or generate the config file from my dotfile installation scripts.

[mpilgrem]

stack path --global-config reports the location of config.yaml, and its location on Windows is documented in the online documentation: https://docs.haskellstack.org/en/stable/yaml_configuration/#yaml-configuration