cabal new-clean #5357
cabal new-clean #5357
Conversation
|
Looks ok, but I think that because we extend the install command, this will give the new-clean command a bazillion flags that are effectively unused and so unnecessary. Have a look at the project orchestration module and see if we can get ahold of a dist dir layout without needing much more than the GlobalFlags. |
| ( removeDirectoryRecursive ) | ||
|
|
||
| cleanCommand :: CommandUI (ConfigFlags, ConfigExFlags, InstallFlags, HaddockFlags) | ||
| cleanCommand = Client.installCommand |
dcoutts
Jun 1, 2018
Contributor
Why is it derived from the install command? Do we need so many flags?
Why is it derived from the install command? Do we need so many flags?
|
|
||
| let distDir = distDirectory (distDirLayout baseCtx) | ||
|
|
||
| removeDirectoryRecursive distDir |
dcoutts
Jun 1, 2018
Contributor
Ahh I see, so using the ProjectOrchestration it looks like we need all this info just to establish the dist dir layout. I strongly suspect however that we could construct the dist dir layout from a whole lot less, and then we wouldn't need to take all these various sets of flags, and would not need to derive from the install command UI.
Ahh I see, so using the ProjectOrchestration it looks like we need all this info just to establish the dist dir layout. I strongly suspect however that we could construct the dist dir layout from a whole lot less, and then we wouldn't need to take all these various sets of flags, and would not need to derive from the install command UI.
|
@dcoutts I know this was covered in IRC but just for others/posterity, the reason it's like that is to support removing individual targets, which requires knowing most of the build information. |
|
Huh, was |
|
Do we want to keep the wildly argumentative Even dropping the functionality, there are a few things that we can't get around being able to know (unless we want to only support default use): dist dir prefix and project file name. That's not that bad, though. |
|
I like that a lot better, and personally I don't know if the trade-off in complexity is worth it. If it's going to know how to map a target into the information it needs to clean things up, it'll need to know enough to build stuff. |
typedrat
dismissed
dcoutts’s
stale review
Made changes in question, no longer uses the complex UI.
|
It is now properly documented, and unless we really want target-specific cleaning enough to add the substantial complexity increase, I believe this just needs squashing and merging. |
|
I agree that granular |
|
Code LGTM, but I'd like the documentation to explicitly list the supported flags, especially |
|
|
||
| ``cabal new-clean [FLAGS]`` cleans up the temporary files and build artifacts | ||
| stored in the ``dist-newstyle`` folder. By default, it removes the entire folder, | ||
| but it can also selectively remove the build artifacts and spare the caches within. |
23Skidoo
Jun 10, 2018
Member
I guess this is no longer true? Or does this mean --save-config? In any case, the wording is a bit vague.
I guess this is no longer true? Or does this mean --save-config? In any case, the wording is a bit vague.
23Skidoo
Jun 10, 2018
Member
Also please document the distPref and projectFile flags here.
Also please document the distPref and projectFile flags here.
typedrat
Jun 10, 2018
Author
Collaborator
That does mean --save-config.
Those flags aren't documented for any of the other commands that take them, they're exactly the same as the ones of the same meaning taken by every other new- command so far, just replicated so I don't drag in every flag down to the municipal flag of Kansas City to get the two things I need.
That does mean --save-config.
Those flags aren't documented for any of the other commands that take them, they're exactly the same as the ones of the same meaning taken by every other new- command so far, just replicated so I don't drag in every flag down to the municipal flag of Kansas City to get the two things I need.
| @@ -1,6 +1,9 @@ | |||
| -*-change-log-*- | |||
|
|
|||
| 2.4.0.0 (current development version) | |||
| * Completed the 'new-clean' command (#5357). By default it removes | |||
| the entire 'dist-newstyle' directory, but can also selectively remove | |||
23Skidoo
Jun 10, 2018
Member
but can also selectively remove only build artifacts.
Seems like this bit also needs updating/rewording.
but can also selectively remove only build artifacts.
Seems like this bit also needs updating/rewording.
| cleanProjectFile (\pf flags -> flags {cleanProjectFile = pf}) | ||
| (reqArg "FILE" (succeedReadE Flag) flagToList) | ||
| , option ['s'] ["save-configure"] | ||
| "Save configuration, only remove build artefacts" |
quasicomputational
Jun 10, 2018
Contributor
s/artefacts/artifacts/
s/artefacts/artifacts/
| } | ||
|
|
||
| cleanAction :: CleanFlags -> [String] -> GlobalFlags -> IO () | ||
| cleanAction CleanFlags{..} _ _ = do |
quasicomputational
Jun 10, 2018
Contributor
Maybe fail on unexpected arguments, so that, if we want to extend new-clean, we won't be breaking any code mistakenly relying on being able to pass junk on the command line.
Maybe fail on unexpected arguments, so that, if we want to extend new-clean, we won't be breaking any code mistakenly relying on being able to pass junk on the command line.
typedrat
Jun 10, 2018
Author
Collaborator
You're right, that's pretty important/basic.
You're right, that's pretty important/basic.
|
Oh, changelog note? Actually I'll go ahead and write one up myself. |
I think it needs some clean-up most likely, but by my understanding of what it's supposed to do, it's at least feature complete.
Please include the following checklist in your PR:
[ci skip]is used to avoid triggering the build bots.Please also shortly describe how you tested your change. Bonus points for added tests!
Fixes #2957