clean behavior is confusing
Metadata
Current evaluation
The 2016 clean/redo UX proposal remains open; modern Snapcraft still exposes clean, while the requested un/re commands are absent from the current command set.
Suggested action: needs triage
Reason: The report includes concrete failures and received maintainer acknowledgement, and a 2020 commenter still reported that part-specific cleaning did not produce snaps. However, its 2016 assumptions and exact un/re CLI predate the current craft-application-based lifecycle implementation, so the remaining behavior and replacement UX need fresh reproduction and design triage.
Evaluated by: mr-cal-bot
Impact:
65
Quick Win:
8
Complexity:
78
Confidence:
72
Actionability:
58
Issue body
When using snapcraft in practice I've been often stumbling upon the behavior of "cleaning".
Several small nits that come in mind right now:
1. Forcing a particular stage does not work
If one types "snapcraft build some-part", this should indeed build the part. Right now it skips if it was already done before, which is a fine behavior when a part name is not given, but when the developer requested a specific part, it should actually respect the request rather than assuming a cached result is okay.
2. "snapcraft clean" doesn't always work
For example:
% snapcraft clean --step snap
'snap' is not a valid step for part 'qt5-packages'
3. Removing content doesn't work
This is the most obvious way to "clean" when one really cannot tell snapcraft what to do. Just nuke the phase content (e.g. "rm -rf ./snap/"). Instead of taking the cue that the directory is simply not there, snapcraft barfs on internal state:
% rm -rf snap
% snapcraft snap
Skipping pull qt5conf (already ran)
(...)
[Errno 2] No such file or directory:
'/home/niemeyer/src/makemkv/snap/bin/qt5-launch'
To recover from this state I had to nuke the parts/qt5conf path, which is not intuitive.
We need to urgently improve the experience of people re-running stages, as this is foundation of the try-and-run cycle.
[Impact]
* `snapcraft clean` is a convoluted cli to manage states for parts.
* This introduces un and re prefixes for the lifecycle commands available for snapcraft
[Test Case]
* Run snapcraft prime
* Run snapcraft reprime
* Verify the lifecycle step is rerun.
* Repeat for pull, build and stage
* Run unprime, unstage, unbuild and unpull
* Run snapcraft reprime <part-name>
* Verify the lifecycle step for only <part-name> is rerun.
* Repeat for pull, build and stage
* Run unprime, unstage, unbuild and unpull for <part-name>
* Verify only <part-name> is cleaned.
* Run snapcraft clean with and without <part-name> and -s <step> and verify it still works with a deprecation message shown to use the new syntax.
[Regression Potential]
* This should had minimal effect on regressions as the clean command is staying for backwards compatibility.
* The un and re commands will be UI modifications not touching the lower layers of snapcraft that manage states.
* The "re" commands are totally new feature but with minimal impact (per plugin).
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
65
Quick Win:
8
Complexity:
78
Confidence:
72
Actionability:
58
|
needs triage | The 2016 clean/redo UX proposal remains open; modern Snapcraft still exposes clean, while the requested un/re commands are absent from the current command set. | |
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
14
Complexity:
67
Confidence:
88
Actionability:
72
|
keep open | Partly addressed cleanup regressions remain: targeted clean is safer, but the proposed undo/redo lifecycle commands and clear rerun semantics are still absent from current Snapcraft. | |
| qwen/qwen3.6-35b-a3b |
Impact:
60
Quick Win:
7
Complexity:
40
Confidence:
40
Actionability:
20
|
keep open | Feature request to improve snapcraft clean/rebuild UX with new 're' and 'un' prefixed commands; proposed solution not found in current codebase. | |
| qwen/qwen3.8-27b |
Impact:
45
Quick Win:
25
Staleness:
90
Complexity:
45
Confidence:
55
Support Request:
10
|
close stale | Snapcraft 'clean' UX is confusing: forcing a part is skipped when cached, 'clean --step' errors, and removing phase content breaks internal state. Body specs un/re lifecycle commands and deprecating clean. 10 yrs old, last activity 5.3 yrs ago, craft-5 milestone. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
80
Confidence:
90
Support Request:
10
|
close stale | Reports confusing behavior in snapcraft's clean and stage forcing mechanisms, proposing new re/un CLI prefixes to improve lifecycle management. Unaddressed for over a decade. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
75
Confidence:
90
Support Request:
15
|
close stale | Feature request to improve snapcraft's build caching and cleaning UX by introducing re/un prefixes for lifecycle steps. Unaddressed for over a decade with no maintainer interaction. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
45
Confidence:
90
Support Request:
20
|
close stale | Report on confusing snapcraft clean behavior with proposed re/un prefix commands. Inactive for over 5 years, originates from an older project version with no maintainer engagement. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
snapcraft (launchpad)#1593868
(confidence 80%)
A 2016 commenter explicitly identified bug #1593868 as experiencing similar cleaning behavior.
Related issues
No related issues found above the similarity threshold.