Python plugin: file conflicts when using the plugin with a custom version of Python from another part
Metadata
Current evaluation
Snapcraft 2.44 Python plugin bundles default Python 3.5 when a custom Python 3.7 is built in another part, causing file conflicts. Root cause: stage_packages evaluated too early. No maintainer response; predates Snapcraft 3.x which uses craft-parts venv-based Python plugin without stage_packages.
Suggested action: close stale
Reason: The issue targets Snapcraft 2.44 (2.x codebase) from ~6.8 years ago with zero maintainer interaction. The current Snapcraft 3.x uses craft-parts, where the Python plugin (craft_parts/plugins/python_plugin.py) no longer has a stage_packages property and instead uses a venv-based approach, making the original root cause (premature stage_packages evaluation) no longer applicable to the current codebase.
Impact:
20
Quick Win:
12.0
Staleness:
95
Complexity:
40
Confidence:
70
Support Request:
10
Issue body
My use-case is as follows: I need to snap a package that supports Python 3.7 only, so I added the compilation of Python 3.7 as a separate part to my snap, similarly to the following snippet:
parts:
python37:
source: https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz
source-type: tar
source-checksum: md5/93df27aec0cd18d6d42173e601ffbbfd
plugin: autotools
configflags:
- --prefix=/usr
build-packages: ***omitted***
stage-packages: ***omitted***
stage:
- -usr/lib/python3.7/test
- -var
my-package:
plugin: python
source: .
requirements: ./requirements.txt
after:
- python37
override-pull: |
...some custom script that is probably not relevant...
snapcraftctl pull
override-prime: |
snapcraftctl prime
...some custom script that is probably not relevant...
During the first build, the Python plugin fails to detect that another version of Python has already been built and staged in another part so it includes the default Python version (3.5) in the "my-package" part, leading to conflicts between "my-package" and "python37"; in particular, the following files are present in the install area of both parts:
/usr/bin/2to3
/usr/bin/pydoc3
/usr/bin/python3
If my understanding is correct, the Python plugin should be able to detect that I have built Python 3.7 in another part and should simply use that instead of bundling Python 3.5.
Cleaning the `my-package` part and rebuiling everything from there seems to resolve the problem, but it's not an ideal experience.
It is also possible to work around the issue by not staging the conflicting files from `my-package`, but it still means that there are two versions of Python in my snap, even though one would be enough.
I managed to track the bug down to the part that the `stage_packages` property in the Python plugin is evaluated right at the beginning of the build (when there is no `python37` part built yet), and that's why the plugin infers that it should bundle Python 3.5 with the `my-package` part. If the `stage_packages` property were evaluated _later_, right before starting to build `my-package`, it should be able to infer that my custom Python is already compiled.
Snapcraft version: 2.44 (I would use Snapcraft 3.x if I could, but I'm preparing a snap for a Raspberry Pi so I'm using classic on Ubuntu Server 18.04, which provides only Snapcraft 2.44 within the classic environment).
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
20
Quick Win:
12.0
Staleness:
95
Complexity:
40
Confidence:
70
Support Request:
10
|
close stale | Snapcraft 2.44 Python plugin bundles default Python 3.5 when a custom Python 3.7 is built in another part, causing file conflicts. Root cause: stage_packages evaluated too early. No maintainer response; predates Snapcraft 3.x which uses craft-parts venv-based Python plugin without stage_packages. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
55
Confidence:
90
Support Request:
10
|
close stale | Python plugin bundles default Python instead of detecting a custom version built in another part, causing file conflicts. The report is over six years old, lacks maintainer response, and targets the unsupported Snapcraft 2.44 release. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
40
Confidence:
85
Support Request:
10
|
close stale | Python plugin bundles default Python instead of detecting a custom Python built in another part, causing file conflicts. Untriaged, inactive for ~6.7 years, specific to obsolete Snapcraft 2.44. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
45
Confidence:
90
Support Request:
10
|
close stale | Python plugin bundles default Python causing file conflicts when a custom Python part is used. Untriaged, inactive for ~6.7 years, reported against Snapcraft 2.44. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
45
Confidence:
90
Support Request:
15
|
close stale | Snapcraft Python plugin bundles default Python instead of detecting a custom Python part, causing file conflicts. Reported for v2.44 with no maintainer response in over six years. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1617907 Two python parts in the same snapcraft.yaml result in not installing the python correctly | snapcraft (launchpad) | open | Stage-time file conflict when two python3 parts share the same interpreter in one snapcraft.yaml (snapcraft 2.14, ~2019). No labels, 0 comments, no maintainer interaction in ~10 years; the old python plugin was later rewritten, so the conflict no longer applies. | |
| #1882994 [4.0.4][strict] usage of the python plugin forces the python3 interpreter to be shipped in the snap | snapcraft (launchpad) | closed | Closed without resolution. The python plugin forces python3 into the snap, causing runtime path conflicts. Likely abandoned or superseded by newer snapcraft plugin versions. | |
| #1613899 Two python parts have common dependencies file conflicts occur | snapcraft (launchpad) | closed | Closed without resolution or comments. The file conflict error when multiple Python parts share common dependencies was abandoned, likely superseded by updated Snapcraft staging logic. |