stack clean should be more thorough by default

[simonmichael]

Several times I have been caught out by expecting stack clean to reset state and fix some transient failure, then finding out that only removing the .stack-work directories was sufficient. And I have only just now discovered stack clean --full. In the most recent example two of us spent several hours troubleshooting weird NFData version-skew-ish doctest failures on one machine, which stack clean did not fix. Somewhat related: #2278, #2936 and #3152.

We were using stack 1.6.3 (and recent HEAD in my case). I don't know how to reproduce the failure state. I expected clean to reset state and be pretty much equivalent to starting with fresh clone of the project. Instead the doctest failures persisted until we tried a fresh clone (and then remembered to try manually removing .stack-work). clean's --full flag was not obvious.

[mgsloan]

Makes sense to me. In favor of deprecating --full, and adding a flag to instead just use cabal clean.

[adrianwong]

Stupid question: with this enhancement, will stack clean fail if cabal is not already on PATH?

[mgsloan]

@adrianwong Nope, the cabal command is the cabal-install package / executable, which stack only uses for solver and building ghcjs. The usage of cabal for cleaning is instead using the compiled Setup.hs. For simple build types, the Setup.hs is a simple invocation of a function in the Cabal library. So, in a way there are two different libraries / executables that are both called "cabal", and stack mostly just uses the lower level one, called Cabal.

[vanceism7]

I can try my hand at this one if no one else is doing it yet

[vanceism7]

Hey @mgsloan, do you mean to just add a warning in the cli when the --full flag is used, and adding a new flag like --shallow? Or should I add a new clean command which actually does a full clean by default (In addition to the deprecated warnings)?

[mgsloan]

@vanceism7 I believe I meant the latter - that clean would do --full by default, and some other flag cause it to do cabal cleans.

It is possible that might not be an expected behavior change. Perhaps it would be safer to require specifying either --shallow (or some other name) or --full. Perhaps @mihaimaruseac , @snoyberg , or some other maintainer has an opinion on what to do here?

[dbaynard]

The behaviour of --full is more like a purge. If the concern is changing existing behaviour, then introducing stack purge as a synonym for stack clean --full would help. In particular, as a new command, it would be listed alongside clean and would make clear that clean doesn't clear everything.

It is still not clear from the docs what stack clean means — would it be accurate to say the following?

stack clean

Delete the local working directories containing compiler output. e.g. …

Use stack clean <specific-package> to delete the output for package specific-package only.

stack purge

Delete the local stack working directory, including extra-deps, git dependencies and the compiler output. Does not delete any snapshot packages, compilers or installed programs.

Also

stack/src/Stack/Clean.hs

Line 57 in ac2c759

-- ^ Delete the "dist directories" as defined in 'Stack.Constants.distRelativeDir'

should point to Stack.Constants.Config.distRelativeDir.

[vanceism7]

Yea, the main issue I was thinking about is preserving backward compatibility. But I think in general it makes sense to use a stack purge command/synonym instead of changing the default behavior of clean. From my experience with other systems (such as dotnet cli), clean only deletes any files generated in a build, it doesn't clear out the entire bin folder. I'll add stack purge and see what I can do to make the documentation a little clearer. Thanks for the input everyone!