Cabal should not store any data in %AppData%

[Mistuke]

On Windows, cabal seems to put it's data in %AppData%, which is not the right place for such data.
Instead it should use %LOCALAPPDATA%.

%AppData% on machines which are domain joined with roaming profiles will be synced back and forth to the domain controller on login/logout. They also eat away at your profile quota while the information isn't very useful on another machine.

Also since the folder contains binaries it may be subjected to virus scans further slowing syncing.

[23Skidoo]

If we do this change, we should communicate it to HP maintainers, because they'll need to fix PATH-updating code in the Windows installer.

/cc @randen

[ezyang]

👍 . Unfortunately, if we want people to not upgrade Cabal and suddenly discover everything is missing, some fiddly transition code will need to be written. Maybe writing the transition code is not worth it.

[Mistuke]

We don't have to strictly migrate the data, if the old data is left as is, and cabal just uses the new directory, then we could just emit a warning and instruct the users to move the folder. Even if they don't the packages are still registered with ghc-pkg so they'll continue to work.

cabal's resolvers won't know of them but that'll only mean some packages will get re-installed. But unless I'm mistaken, nothing will strictly break will it?

[hvr]

We've traditionally used getAppUserDataDirectory from the directory package; how would we go about changing this? Does this need changes to directory or would we stop using getAppUserDataDirectory?

Somewhat related, a related change for other operating systems would be #680 (XDG compliance)

[randen]

(This issue mentioned cabal's data; does that mean general "data" including the binary? It sounds like it, but just want to be sure. If so, then I will submit the HP issue to track.)

[ezyang]

@randen Yes, I think it covers installed executables. I think the biggest problem with unceremoniously changing the install location is when people try to cabal install fooexe and the new executable doesn't show up in their path. Though, I suppose we do have a warning for this case...

[Mistuke]

@hvr I think directory should get patched, or at the least a separate function added to it for this. ghc-pkg has the same problem. though since that only writes small text based metadata I can live with that.

@randen yes, I'm not worried at all about the actual package metadata, it's more the binaries. Remember that especially on Windows these are statically linked behemoths. And with split-sections your static archives get bigger too since you now have the hear overhead for all the different sections.

@ezyang yes, the paths would be a slight issue. I think we can communicate the change loudly enough though.

[Mikolaj]

Duplicate of #1857