Remove GHC/git tarballs after installation

[conklech]

As of 0.0.2, when stack installs GHC and git on Windows, it leaves both the compressed and uncompressed (!) installation tarballs in AppData\Local\Programs\stack\i386-windows. This consumes almost 900MB unnecessarily. Manual deletion resolves but should be unnecessary.

[snoyberg]

The compressed file was actually a conscious choice based on requests from people who wanted to avoid an extra download in the case of needing (for some reason) to delete the installation. How do you feel about keeping that around?

I agree with you completely on the uncompressed. There's no reason to keep that.

[conklech]

The compressed tarball is something like 70-80 MB. That's probably reasonable on all but the most space-starved systems. I wouldn't be outraged at having it maintained by default, but there's a potential for accumulating cruft. The set of conditions under which stack deletes the tarballs should not be empty, otherwise a user would build up a big collection of outdated tarballs. Likewise providing an uninstallation method or documentation.

Currently, stack puts large files in two locations on Windows: AppData\Local\Programs\stack\ and AppData\Roaming\stack\. Would it be appropriate to unify those so the cache/snapshot/installation space usage is clearer? (MinGHC, incidentally, installs its copy of GHC in AppData\Local\Programs\minghc-x.x.x. If it's not intended for stack to replace or merge with MinGHC, perhaps that double copy could also be eliminated.)

[snoyberg]

It's intentional that stack installs programs to AppData\Local, as this is a semi-standard on Windows. The idea being that large installs shouldn't go in AppData\Roaming, which moves across active directories. (There was some MinGHC issue where we discussed it, I don't remember the number offhand.)

[conklech]

But why are the snapshots in Roaming? A roaming user would have to reinstall GHC on every new workstation anyway; does roaming the potentially-large snapshot folder, which "just" contains build artifacts, add much value?

(These are real, not rhetorical questions, by the way; the MS docs I've seen are pretty vague on policy here, and it's been a long time since I've worked in a roaming environment. At that time, the big pain point was that logging in took forever because of various huge blobs in the roaming folder that had to be copied each time. I don't know if that's still an important concern.)

[snoyberg]

The real reason is because that's what System.Directory tells us to do. Is that a good reason? I'm not sure. I put the GHC installations in a different directory because those obviously fit the definition of what the MS docs said for Local\Programs. I'm not sure if the artifacts that stack is generating fall into that category.

[snoyberg]

Deleting the .tar file is implemented on master now. I'd like to support deleting old GHC installations and archives via the planned stack rm command, does that make sense?

[rvion]

I think it does

[conklech]

In conjunction with the fix and #133, this issue is mostly resolved.

Moving from "bug fix" to "design question" mode: is preserving the compressed tarball the correct default action?

The use case @snoyberg mentioned was allowing reinstallation of GHC without redownloading. Since the stack GHC installation is (presumably) immutable and doesn't affect anything but stack, wouldn't space-saving be the only reason to delete it? It seems like a relatively narrow use-case; I'm imagining someone who wants to occasionally test with multiple compilers on a limited connection without leaving a gig or two of GHC installation lying around. Set against that is a 10% space bloat for all users.

Would it make more sense to provide and document a --preserve-ghc-tarball option to support that use case, and delete the tarball after installation by default?

[snoyberg]

I still think it's the correct default action: disk space is cheap, and there are certainly ways someone could accidentally mess up their installation and want to be able to easily reinstall. It can also help with debugging if we suspect there may be some corruption in place.

[snoyberg]

Despite the disagreement on design here, I'm going to close this issue, as I don't think we're going to get further on agreement.