cabal new-clean

[typedrat]

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:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [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

[dcoutts]

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.

[typedrat]

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

[typedrat]

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

[typedrat]

Huh, was when exported from somewhere else but only in 7.10.3? I'm trying to figure out why that CI error is showing up.

[typedrat]

Huh, was when exported from somewhere else but only in 7.10.3? I'm trying to figure out why that CI error is showing up.

[typedrat]

Do we want to keep the wildly argumentative new-clean that allows selective cleaning (and refine that feature so it works better than it does now) or do we give up on that functionality to be able to simplify the flags it will take?

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.

[typedrat]

Do we want to keep the wildly argumentative new-clean that allows selective cleaning (and refine that feature so it works better than it does now) or do we give up on that functionality to be able to simplify the flags it will take?

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.

[typedrat]

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]

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]

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.

[typedrat]

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.

[23Skidoo]

I agree that granular clean is not required for 3.0, for which our main goal is feature parity.

[23Skidoo]

I agree that granular clean is not required for 3.0, for which our main goal is feature parity.

[23Skidoo]

Code LGTM, but I'd like the documentation to explicitly list the supported flags, especially --save-config.

[quasicomputational]

Oh, changelog note? Actually I'll go ahead and write one up myself.

[quasicomputational]

Oh, changelog note? Actually I'll go ahead and write one up myself.