-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual env runtime fix for running as Linux AppImage. #1863
Conversation
mu/virtual_environment.py
Outdated
os.unlink(self.interpreter) | ||
os.symlink(sys.executable, self.interpreter) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've seen so many weirdness with how the virtual environments copy, create, or symlink the executables that I wouldn't be surprised if this breaks somewhere.
I think either the venv or virtualenv modules might have some utility to do this kind of thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so the venv module has an upgrade
option:
--upgrade Upgrade the environment directory to use this version
of Python, assuming Python has been upgraded in-place.
Not sure if this would fall within the "assuming Python has been upgraded in-place", maybe not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally agreed: the --upgrade
venv
option migh serve us, but we're using virtualenv
which, from what I've seen, does not expose such a "feature".
Maybe for "minimal guarantees" we could use the --symlinks
(which defaults to True
) when calling python -m virtualenv
in mu/virtual_environment.py:773
. Other than that, not really sure... :)
Updated the PR:
@tjguk, @carlosperate, @ntoll: your input is welcome. :) |
I'm very low on bandwidth to be able to test this until the end of the month, but the code looks good to me and I'd be happy for the PR to be merged it if you've already tested it 👍 |
I'd suggest to wait for the v1.1 final release before we merge AppImage support, we can then start testing this on Linux on with the first 1.2-beta. |
Ack on post 1.1. |
NOTE:
|
"-p", | ||
sys.executable, | ||
"-q", | ||
"" if self._is_windows else "--symlinks", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out the --symlinks
flag was only added to the virtualenv
pacakge in version 20.0.0.
We currently support v16 and Debian/Raspbian Buster ships with v15, so in those environments this fails the virtualenv creation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FACT:
pup
PR I found a serious limitation.python
executable in Mu's installation -- no longer exists (it does, but each time under a different path).THIS PR:
PS: Isn't packaging fun? :)