### Check existing issues - [x] I've verified that this bug isn't described by any existing issues. ### Bug description When building a snap that stages its own Python interpreter with `stage-packages` (most notably, on core26) and uses the Python plugin to build, you can end up with two options for Python interpreters making it into the final artifact. There's the system Python from `stage-packages`, at `/bin/python3`, and then the venv Python from the plugin at `/usr/bin/python3`. The venv Python is typically a symlink to the system Python, but the issue arises with things like `PYTHONPATH`. Since these "appear" as different interpreters, they'll search different things for imports, environments, and things such as `pyvenv.cfg`. Most applications want and expect to be ran with the system Python, but the venv Python appears on the `PATH` first. Some current workarounds are: - Unstage the venv interpreter on the Python plugin part - Use layouts to bind `/usr/bin/python3` to `$SNAP/bin/python3` - Mangle your app's `PATH` to put `/bin` first The fix that the Starcraft team seems to agree on is to patch all shebangs to point to `/bin/python3` instead of `/usr/bin/env python3`, that way this interpreter "selection" is more consistent. Relevant forum post: https://forum.snapcraft.io/t/core26-bundled-python-changes/50178/17 ### Steps to reproduce Build a core26 Python project that stages its own Python interpreter and builds with the Python plugin. ### Environment N/A ### snapcraft.yaml ```yaml N/A ``` ### Log output ```shell N/A ```