stack rm command #133

Open
snoyberg opened this Issue May 31, 2015 · 23 comments

Comments

Projects
None yet
@snoyberg
Contributor

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.

Show comment
Hide comment
@snoyberg

snoyberg Jun 23, 2015

Contributor

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

Contributor

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.

Show comment
Hide comment
@rvion

rvion Jun 23, 2015

Contributor

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

Contributor

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.

Show comment
Hide comment
@snoyberg

snoyberg Jun 23, 2015

Contributor

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

Contributor

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.

Show comment
Hide comment
@conklech

conklech 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.

+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.

Show comment
Hide comment
@radix

radix Jun 23, 2015

Contributor

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 :)

Contributor

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.

Show comment
Hide comment
@rvion

rvion Jun 23, 2015

Contributor

@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

Contributor

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.

Show comment
Hide comment
@conklech

conklech 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.

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.

Show comment
Hide comment
@radix

radix Jun 23, 2015

Contributor

@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?

Contributor

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.

Show comment
Hide comment
@cies

cies Jul 10, 2015

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

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.

Show comment
Hide comment
@snoyberg

snoyberg Jul 10, 2015

Contributor

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

Contributor

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.

Show comment
Hide comment
@conklech

conklech 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.

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.

Show comment
Hide comment
@cies

cies 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.

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.

Show comment
Hide comment
@duplode

duplode Jul 22, 2015

Contributor

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.

Contributor

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.

Show comment
Hide comment
@chreekat

chreekat Jul 22, 2015

Contributor

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?)

Contributor

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.

Show comment
Hide comment
@conklech

conklech 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.

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.

Show comment
Hide comment
@chreekat

chreekat Jul 22, 2015

Contributor

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)
.

Contributor

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.

Show comment
Hide comment
@ches

ches 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.

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.

Show comment
Hide comment
@mgsloan

mgsloan May 6, 2016

Collaborator

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.

Collaborator

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.

Show comment
Hide comment
@CMCDragonkai

CMCDragonkai Apr 9, 2017

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

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

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Apr 22, 2017

Collaborator

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

Collaborator

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.

Show comment
Hide comment
@CMCDragonkai

CMCDragonkai Apr 24, 2017

@mgsloan What does stack docker gc do?

@mgsloan What does stack docker gc do?

@borsboom

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Apr 24, 2017

Contributor

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

Contributor

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.

Show comment
Hide comment
@chris-martin

chris-martin Oct 1, 2017

Contributor

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.

Contributor

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.

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