New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove GHC/git tarballs after installation #376

Closed
conklech opened this Issue Jun 22, 2015 · 10 comments

Comments

Projects
None yet
3 participants
@conklech

conklech commented Jun 22, 2015

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 snoyberg added this to the 0.2.0.0 milestone Jun 22, 2015

@snoyberg snoyberg self-assigned this Jun 22, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 22, 2015

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

This comment has been minimized.

conklech commented Jun 22, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 22, 2015

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

This comment has been minimized.

conklech commented Jun 22, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 22, 2015

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 added a commit that referenced this issue Jun 23, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 23, 2015

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?

@snoyberg snoyberg removed this from the 0.2.0.0 milestone Jun 23, 2015

@snoyberg snoyberg removed their assignment Jun 23, 2015

@rvion

This comment has been minimized.

Contributor

rvion commented Jun 23, 2015

I think it does

@conklech

This comment has been minimized.

conklech commented Jun 23, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 24, 2015

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 snoyberg modified the milestone: 0.2.0.0 Jun 25, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

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.

@snoyberg snoyberg closed this Jun 25, 2015

@snoyberg snoyberg removed the in progress label Jun 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment