Skip to content
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

stack rm command #133

Closed
snoyberg opened this issue May 31, 2015 · 27 comments

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented May 31, 2015

  • Without arguments, lists all local GHCs and snapshots
  • Takes output from previous command and deletes relevant directories
  • Maybe have a --all flag?

Thoughts on this from anyone?

@snoyberg snoyberg modified the milestones: Second release, Third release May 31, 2015
@snoyberg snoyberg modified the milestones: Later improvements, First stable release (0.1.0.0?), 0.2.0.0 Jun 9, 2015
@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Jun 23, 2015

Can also be used to delete old GHC/Git archives (see #376, and pinging @conklech

@rvion

This comment has been minimized.

Copy link
Contributor

@rvion rvion commented Jun 23, 2015

Without arguments, lists all local GHCs and snapshots

do you mean: without arguments, list all local GHC and snapshots and ask the user to re-run the command with one or several of them after stack rm

Takes output from previous command and deletes relevant directories

not sure to understand

Maybe have a --all flag?

+1

@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Jun 23, 2015

Yes, that's what I meant. My idea is that the output will be something like:

Can delete:

* stack rm ghc-7.8.4
* stack rm ghc-7.10.1
* stack rm lts-2.15

Running any of those commands will delete the relevant directories

@conklech

This comment has been minimized.

Copy link

@conklech conklech commented Jun 23, 2015

+1 from me, too. --all would be constructive, and ought to be mentioned alongside the installation instructions; it should be best practice to have a documented uninstallation procedure.

@radix

This comment has been minimized.

Copy link
Contributor

@radix radix commented Jun 23, 2015

I'm slightly uneasy about calling this "rm", it just doesn't seem like the right name for it. Maybe "clean" or "cleanup"?

Feel free to ignore my bikeshedding :)

@rvion

This comment has been minimized.

Copy link
Contributor

@rvion rvion commented Jun 23, 2015

@radix I understand it may not feel like the best name, but I think lots of people are used to this one.
I would still go for stack rm because of git rm and docker rm, that will be used by most users of stack

@conklech

This comment has been minimized.

Copy link

@conklech conklech commented Jun 23, 2015

Two issues arose from #376 that are relevant here:

  1. Should we give an option to delete just the GHC tarball without nuking the installation? And should stack rm ghc-7.8.4 remove or preserve the installation tarball? See #376 for discussion of the rationales for each option.

  2. On Windows, stack also installs its own git. That should be on the list as well.

@radix

This comment has been minimized.

Copy link
Contributor

@radix radix commented Jun 23, 2015

@rvion Funny, I had exactly those kinds of commands in mind, and it gave me the opposite reaction. Maybe I don't understand the goal of stack rm enough. But with git rm it's obvious that the thing you'd want to remove is a file. and docker rm would remove a container. But stack doesn't have any one domain that rm would obviously apply to... The idea is for stack rm to delete either GHC installations or the cached packages in a snapshot directory?

@snoyberg snoyberg modified the milestones: 0.2.0.0, 0.3.0.0 Jul 2, 2015
@cies

This comment has been minimized.

Copy link

@cies cies commented Jul 10, 2015

What about stack purge? And is the --all flag the same as rm -rf ~/.stack ?

@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Jul 10, 2015

I'm open to any bikeshedding, purge sounds fine to me. And yes, I think --all would be roughly equivalent to rm -rf ~/.stack

@conklech

This comment has been minimized.

Copy link

@conklech conklech commented Jul 10, 2015

Perhaps clean would be better. The idea is only to remove objects that can be mechanically recreated by downloading and/or recompiling. It's not really garbage-collecting, since we have no concept of things being "live". But it's not a potentially-irreversible operation like rm implies. The only side-effect is to increase the cost of future operations (and perhaps require stack setup).

Incidentally, that assumption would be contradicted if clean --all deleted .stack/global/stack.yaml or any other user-defined configuration files; perhaps there should be a runtime or documentation warning if such a file will be removed.

@cies

This comment has been minimized.

Copy link

@cies cies commented Jul 12, 2015

I don't have strong feelings with either of the names. The reason I suggested purge was that (1) rm reminds me most of git rm, actually removing one or more files by path/filename, (2) clean reminds me most of make clean which deals with files created during a build of this-very-project, and (3) purge reminds me of dropping some cached objects.

@duplode

This comment has been minimized.

Copy link
Contributor

@duplode duplode commented Jul 22, 2015

I was going to ask about this in #115. Good to see that it is in the plans - uncontrolled proliferation of sandboxes is an annoyance with the vanilla cabal sandbox workflow; a stack purge would be the last step towards solving that issue.

@chreekat

This comment has been minimized.

Copy link
Contributor

@chreekat chreekat commented Jul 22, 2015

I like clean because of symmetry with aptitude clean: "Removes all previously downloaded .deb files from the package cache directory (usually /var/cache/apt/archives)." Your experience may vary (YEMV?)

@conklech

This comment has been minimized.

Copy link

@conklech conklech commented Jul 22, 2015

stack clean is a different, already-implemented function, which I think is more like make clean.

Sorry, I thought I had posted a follow-up when I realized my clean proposal had that problem. FWIW, I'm now in the purge camp.

@chreekat

This comment has been minimized.

Copy link
Contributor

@chreekat chreekat commented Jul 22, 2015

Dur, I knew that (about clean). I also like purge.

On Wed, Jul 22, 2015 at 2:04 PM, Christian Conkle notifications@github.com
wrote:

stack clean is a different, already-implemented function

clean :: (M env m) => m ()
,
which I think is more like make clean.

Sorry, I thought I had posted a follow-up when I realized my clean
proposal had that problem. FWIW, I'm now in the purge camp.


Reply to this email directly or view it on GitHub
#133 (comment)
.

@ches

This comment has been minimized.

Copy link

@ches ches commented May 6, 2016

Incidentally, that assumption would be contradicted if clean --all deleted .stack/global/stack.yaml or any other user-defined configuration files; perhaps there should be a runtime or documentation warning if such a file will be removed.

Agreed, slightly more subtlety required than rm -rf ~/.stack. I'd also be annoyed if it nuked ~/.local/bin, perhaps that's obvious if there's no way of knowing what each of those binaries was built with.

I'm not familiar at all with stack's internals, but no doubt this can be done programmatically with better maintainability than some hardcoded paths… but could we enumerate here what this effectively would do? This might capture the wanted PR intent and UX in simple terms, and could help for scripting a solution in the meantime (and perhaps serve as FAQ material until it's ready—e.g. "I have old snapshots eating up GBs of disk that I'm no longer using for active projects, how can I remove them safely?").

For instance, I would assume stack rm <snapshot> would effectively do:

  • rm -rf ~/.stack/snapshots/<arch>/<snapshot>
  • rm -rf ~/.stack/global-project/.stack-work/install/<arch>/<snapshot>
  • …?

And stack rm <ghc>:

  • rm -rf ~/.stack/programs/<arch>/<ghc>*
  • rm -rf ~/.stack/precompiled/<arch>/<ghc>
  • rm -rf ~/.stack/global-project/.stack-work/install/*/*/<ghc>
  • …?

Does that appear complete? Should it operate on a local project's ./.stack-work also (I assume yes)?

Aside: FWIW with reasoning shared so far, I like stack purge.

@mgsloan

This comment has been minimized.

Copy link
Collaborator

@mgsloan mgsloan commented May 6, 2016

My current thought on this is to keep a timestamped log of package, project, and database usages. Not 100% sure we want to keep track of individual package usages. It would allow for more fine-grained garbage collection, but possibly for too much overhead.

The overall idea is that build results which haven't been used for a while are less likely to be used in the future. Similarly to stack docker cleanup, we'd offer interactive selection of build results to remove.

@CMCDragonkai

This comment has been minimized.

Copy link

@CMCDragonkai CMCDragonkai commented Apr 9, 2017

Is there no garbage collection for un-used GHC versions?

@mgsloan

This comment has been minimized.

Copy link
Collaborator

@mgsloan mgsloan commented Apr 22, 2017

@CMCDragonkai Not currently. Could probably have something similar to stack docker gc, and track last usage times for snapshots / compilers.

@CMCDragonkai

This comment has been minimized.

Copy link

@CMCDragonkai CMCDragonkai commented Apr 24, 2017

@mgsloan What does stack docker gc do?

@borsboom

This comment has been minimized.

Copy link
Contributor

@borsboom borsboom commented Apr 24, 2017

@CMCDragonkai I think he meant stack docker clean, which cleans up old Docker images.

@chris-martin

This comment has been minimized.

Copy link
Contributor

@chris-martin chris-martin commented Oct 1, 2017

The garbage collection question definitely needs to be answered in some form or another. If possible, I think I might find a documentation solution preferable to a new command. It would be great if the manual discussed the directory structure of ~/.stack and explained what directories were safe to delete.

@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Mar 20, 2019

@snoyberg snoyberg closed this Mar 20, 2019
@anka-213

This comment has been minimized.

Copy link

@anka-213 anka-213 commented Mar 24, 2019

As a workaround, how would you do this manually? My last attempt at purging old ghc versions manually broke my stack installation.

@dylan-thinnes

This comment has been minimized.

Copy link

@dylan-thinnes dylan-thinnes commented Mar 24, 2019

@snoyberg I'm considering applying using this issue to apply for Google Summer of Code, do you have any pointers to where I could go to look at the feasibility of working on a stack rm/clean, along with other features to mend space usage? If there are other performance improvements you are thinking would specifically be useful over this one, I'd be glad to discuss those too.

I've run into personal issues with stack being too large for my chromebook before, and I'm worried it would put off newcomers to stack to have it use as much space as it does, so needless to say I've been interested in this issue for a while.

@snoyberg

This comment has been minimized.

Copy link
Contributor Author

@snoyberg snoyberg commented Mar 25, 2019

As a workaround, how would you do this manually? My last attempt at purging old ghc versions manually broke my stack installation.

I've deleted GHC versions by deleting ghc-X.Y.Z* in the ~/.stack/programs/$arch-$os directory. I've never had problems with that. I'm not sure how this would have broken your installation.

do you have any pointers to where I could go to look at the feasibility of working on a stack rm/clean, along with other features to mend space usage?

I think just the issue tracker, I don't have anything in particular. It's certainly feasible to add an rm command. A more general gc command for snapshots would require more design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.