isolate parts of a rockcraft build process from each other
Metadata
Current evaluation
Requests per-part build isolation so build-packages and other environment side effects do not leak between parts. It remains open, unlabelled, and without maintainer discussion or a located implementation.
Suggested action: needs triage
Reason: The YAML reproducer concretely shows use-python causing python3.7 to be visible in earlier and later parts, while current lifecycle setup still uses one shared rootfs_dir. With no labels, comments, acceptance criteria, or isolation-related implementation located, this architectural feature needs maintainer triage and its stage/prime data flow and compatibility implications make it complex.
Evaluated by: mr-cal-bot
Impact:
58
Quick Win:
2
Complexity:
91
Confidence:
88
Actionability:
47
Issue body
### What needs to get done
Fully isolate the environment of every part in a rockcraft build (while still allowing data to be passed between them or staged/primed, etc)
### Why it needs to get done
The side effects that one part can have on another are not intuitive. For example:
```yaml
name: python-version-test
base: ubuntu@20.04
version: test
summary: python version test
description: |
python version test
license: GPL-3.0
platforms:
amd64:
parts:
spy-before:
plugin: nil
# override-build: |
# exit 1
use-python:
after: [spy-before]
plugin: nil
build-packages:
- python3.7
spy-after:
after: [use-python]
plugin: nil
# override-build: |
# exit 1
```
It feels counterintuitive that all three parts have `python3.7`:
* `use-python` has it because it defined `build-packages`
* `spy-before` and `spy-after` have it because of `use-python`'s `build-packages`
This feels surprising for two reasons:
* the structure of parts makes them feel like they should be isolated. It does not feel intuitive that the `spy-*` parts get side effects from `use-python`. The idea of each part having its own workspace exists, but really its just its own directory in a shared workspace
* it feels *really* counter-uituitive that `spy-before` has python, since `use-python` is scheduled `after: [spy-before]` [^1]
This feels really error-prone and hard to predict. Coming from something like multi-stage builds in docker, the stages are nicely isolated but facilitate data exchange where its needed. The developer experience feels better when you have that strong isolation available.
^1: I understand this happens because the package install for `build-packages` for all parts happens before other steps in the part lifecycle, but that it happens at all still feels strange
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
2
Complexity:
91
Confidence:
88
Actionability:
47
|
needs triage | Requests per-part build isolation so build-packages and other environment side effects do not leak between parts. It remains open, unlabelled, and without maintainer discussion or a located implementation. | |
| qwen/qwen3.6-35b-a3b |
Impact:
40
Quick Win:
8
Complexity:
60
Confidence:
70
Actionability:
50
|
needs triage | Feature request to fully isolate part environments in rockcraft builds, preventing build-packages from leaking between parts in counterintuitive ways. | |
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
6
Staleness:
75
Complexity:
90
Confidence:
70
Support Request:
10
|
needs triage | Feature request to fully isolate each part's build environment in rockcraft (e.g. build-packages of one part leaking into others), modeled on Docker multi-stage builds. No maintainer response, labels, or activity since filing; the shared build environment is core craft-parts behavior. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
90
Complexity:
80
Confidence:
85
Support Request:
5
|
needs triage | Feature request to fully isolate rockcraft build parts to prevent environment leakage between stages. Open for over two years with no maintainer response, labels, or assignees. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
80
Confidence:
85
Support Request:
10
|
needs triage | Feature request to fully isolate rockcraft build parts to prevent unintended side effects from shared build packages. Currently unlabelled, no maintainer comments, inactive for over a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
80
Confidence:
85
Support Request:
10
|
needs triage | Feature request to fully isolate rockcraft build parts to prevent unintended side effects from shared build packages. Currently untriaged, inactive, and awaiting maintainer assessment. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.