[RFC] Merging into `stack`

[ocramz]

Usually I solve this problem "by hand" but it's great that you wrote a tool that does that.

I was wondering whether it would be worth it to "upstream" the tool's functionality into stack proper.

[juhp]

Yes, thanks, it is a good suggestion - someone also suggested this on Reddit.
I would like to see that done - it will probably take me some time since I am quite busy currently.

[ketzacoatl]

This sounds great! I would be happy to help with the effort, if there is a way to plug in and be useful.

[juhp]

This sounds great! I would be happy to help with the effort, if there is a way to plug in and be useful.

I think the first thing would be to look at the stack code: a while ago I got list merged.
It would probably be good to discuss/propose this in a stack issue too (there might be some existing RFEs? I forget),
since the stack maintainers may well have suggestions/thoughts on this too.

If we can find a time in March, perhaps we could also try to pair-program on this together.

[juhp]

At least I spotted a couple of related stack issues in:
https://github.com/commercialhaskell/stack/issues?q=is%3Aissue+is%3Aopen+gc

[qrilka]

There was a proposal for stack gc for this summer of code and it's quite related to this I think. @snoyberg could you share the details of that and maybe your thoughts on the topic?

[snoyberg]

Here's the draft proposal I sent over to Jasper:

Garbage collection: Stack downloads and stores large files, such as
programs and artifacts. These large files take up disk space
and can often be removed after a period of time, since they
are no longer in use. A new stack gc command could be added
to clean up unused files automatically.

No particular thoughts from my side, other than it would be nice to get the functionality in somehow.

[ocramz]

@snoyberg how are "stale" files and folders determined?

[snoyberg]

I don't have an answer to that. It's part of the project to make that determination.

[juhp]

Well I think in the most general case currently it is not possible to determine that exactly, other than by what are the current installed ghc compilers.
eg How to determine if some ~/.stack/snapshots/x86_64-linux-tinfo6/* cached build is still needed or not by some local project.

The initial stack-clean-old code tried to remove such older directories just based on the date, but that turned out to be completely unsafe: but I think that approach works for a project's .stack-work/install/x86_64-linux-tinfo6/* per ghc version and this is used by stack-clean-old purge-older.

[juhp]

Also if people have opinions on which stack-clean-old commands/behavior would be most attractive to bring to stack, that would be useful input.

[ketzacoatl]

@juhp all of it?

From my personal experience, typical use cases seem to be:

• list disk use by GHC/LTS/etc
• purge a specific GHC/LTS version
• purge everything except a specific GHC/LTS version
• purge compiled modules/etc, leaving GHC