Comments (2)
Hello @nihilox,
Thank you for reporting this issue.
Unfortunately I see no good solution right now in order to recover 100% native Python/venv behaviour with AppImages. However, there is a simple workaround. The problem is actually related to -E
(i.e. ignoring PYTHON*
environment variables). If isolation is done manually, e.g. as:
PYTHONPATH= python -s -m site
then sys.path
is properly set.
The difficulty is that venv seems to rely on symbolic links, at least on Linux. My understanding is that venv site-packages location is determined from the link origin (i.e. sys.executable
). But, when using an AppImage, Python is not called directly, it is mounted at AppImage start to a temporary directory, and then it is called through an AppRun wrapper script. In order to mimic a direct call through a symbolic link, I use the exec command in the AppRun script, e.g. as
(exec -a "$origin" "$target" "$@")
where $target
is the actual Python runtime, inside the mounted AppImage. This properly sets sys.executable
to $origin
. However, when sys.executable
differs from $target
, then Python reads sys.base_prefix
from its (hardcoded) initial installation location, e.g. /usr
, which is no more valid once relocated, e.g. when using an AppImage. Therefore, I instead use the following command:
(PYTHONHOME="$base_prefix" exec -a "$origin" "$target" "$@")
where $base_prefix
points to the mounted AppImage, i.e. $target = $base_prefix/bin/pythonX.Y
. This trick seems to work fine in most cases. But, if the -E
option is used, then it obviously fails since PYTHONHOME
is ignored. This case is detected by the AppRun wrapper script. When -E
is used, then the wrapper directly calls the Python executable inside the AppImage, as
"$target" "$@"
Thus, sys.executable
points to $target
. This is OK for native calls. However, it fails when running inside venv. Then, sys.path
is initialised according to $target
, instead of $origin
.
As stated initialy, I do not have any good solution for now. The hacks that I have implemented for venv have some unsatisfactory side effects (e.g. spoiling PYTHONHOME), and anyway they do not work at 100%. On the other side, I like the fact that sys.executable
points to the AppImage executable (or to a corresponding symbolic link), rather than to a temporary mount point.
from python-appimage.
@nihilox ,
I have updated Python AppImages over the WE. They should now behave properly w.r.t. venv. Therefore, I am closing this issue for now. But, please feel free to re-open it if you still observe malfunctioning.
Technically speaking, I now patch sys.executable
directly at Python runtime. This happens after getpath
has initialised sys.prefix
, etc., but before the execution of site.main
. The latter sets sys.path
according to the result of getpath
, and depending on venv
. With this new method, I don't need to trick Python anymore with the exec
command and using PYTHONHOME
. Thus, Python AppImage should now behave close to native Python. However, in order to do so, I had to slightly modify core Python.
Note that as a side effect, it also patches the issue with pip
not being initialised at venv
creation. Now it should work properly.
from python-appimage.
Related Issues (20)
- AttributeError: module 'importlib' has no attribute 'util' HOT 1
- Feature Request HOT 3
- Python Environment Does Not Work Under Directories With Spaces HOT 4
- {install,build,which} response HOT 1
- Support for manylinux_2_24 and manylinux_2_28 HOT 5
- [Question] Adding wxPython HOT 4
- URL correction request in documentation HOT 1
- xonsh AppImage is broken after Jun changes HOT 3
- PyPy AppImages HOT 3
- License question HOT 5
- _sysconfigdata_m_linux_{{arch}}-linux-gnu.py needs to be relocated HOT 1
- Set rpath also to $ORIGIN/../lib HOT 2
- uuid.getnode() discrepancy HOT 7
- Allow < and @ sign in requirements.txt HOT 2
- how can use this and linuxdeploy to build appimage HOT 2
- Trying to use ranger with python-appimage HOT 7
- Could you add libpython.a files to the AppImages? HOT 2
- Why does this project release often while source code did not change? HOT 5
- python3.12 support/release HOT 2
- [question] Support for relative path based requirements HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-appimage.