isolate parts of a rockcraft build process from each other
Metadata
Current evaluation
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.
Suggested action: needs triage
Reason: The issue has zero comments, no labels, and no maintainer interaction in ~3 years, so it has never been triaged. It is a legitimate architectural feature request (not a bug or support question), but the requested per-part isolation would require changes in the shared craft-parts executor, where the build environment is a single shared context (Executor takes one build_environment for all parts; craft_parts/executor/part_handler.py prepends it to every step), so it needs maintainer assessment of feasibility and scope rather than closure.
Impact:
55
Quick Win:
5.5
Staleness:
75
Complexity:
90
Confidence:
70
Support Request:
10
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 |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
5.5
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. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
75
Confidence:
90
Support Request:
10
|
needs triage | Requests full environment isolation for rockcraft build parts to prevent unintended package side effects and improve predictability. Open, unassigned, and awaiting triage or discussion. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #959 Allow Custom Build Contexts | rockcraft | open | Feature request to allow rockcraft to pull source from outside the project context directory, enabling multi-rock repositories to share common source. Acknowledged by maintainer as cross-craft concern, linked to charmcraft#1079. No implementation exists; last activity ~11.5 months ago. |