Improvements to the PythonPlugin for core24
Metadata
Current evaluation
No evaluation has been recorded for this issue yet.
Issue body
### What needs to get done
The story for Python snaps improved in `core24` but it's still a bit far from optimal. This issue is a bit of a braindump/discussion place for further improvements that we can do when targetting `core24` snaps:
These two suggestions can be applied even if the Snapcraft project doesn't use the `python` plugin:
### 1) Add a linter that warns when a Python symlink points to a "probably invalid" interpreter (like pointing to `/usr/bin/python3` in classic snaps).
Rationale: for the easy case of classic snaps, `/usr/bin/python3` comes from the user's machine and thus who knows which interpreter that is! There are also cases where the symlink can point to gnome-sdk's Python (when using the gnome extension).
### 2) Add a linter that warns when a Python script has the default shebang `#! /bin/env python3`.
Rationale: similarly, because `/bin/env` will use the `PATH` it will very likely not pick up the correct `python3` (the one in `$SNAP/bin/python3`) because by default that directory comes very late in the search order.
These suggestions are for when using the Python plugin specifically, in which case we have more control over the build:
### 3) Add a 'post-prime' step that fixes the shebangs in Python scripts to `#! /snap/<snapname>/current/bin/python3`.
This would also alleviate suggestion 2; when we're getting ready to pack the final snap we know that the "correct" interpreter to use will live in `#! /snap/<snapname>/current/bin/python3`, so we might as well "hardcode" that. We should do that after `prime`, and not during `build`, so that the scripts still work during the build step.
### 4) Improve the interaction between the `python` plugin and the `gnome` extension.
This one is a bit of a stretch-goal; snaps using the `gnome` extension have access to the sdk (during build) and the content snap (during runtime). So a Python project should use the sdk's Python interpreter during build (I assume it has special packages for building), but the content snap's interpreter during runtime. With this it should be straightforward to create a snap that has Python code that uses Gnome packages somehow (maybe Cairo?)
### Why it needs to get done
To improve the UX of Python-based snaps
Evaluation history
No evaluation history available.