Open carlosperate opened 2 years ago
Possible solutions:
--system
flag
Current workarounds for Linux users:
@carlosperate, just released pup
1.0.0a15 that defaults to launching with the -I
flag.
SUGGESTION - You would see alot less newbies (like Me!) running into this if you were to update the Mu install instructions at: https://codewith.mu/en/howto/1.1/install_with_python to recommend installing in a virtual environment. Ref: (Dup Issue mu-editor/mu#2144)
Thanks for the feedback @rickcox!
Technically speaking, the instructions already indicate this:
But it is not very visible and I agree that having this emphasised would likely help users.
This is a follow up from the solution to:
Which was to add the
-I
flag to thepython -m virtualenv ...
command: https://github.com/mu-editor/mu/pull/1921/filesThis is perfect for the installer Mu instances, as everything needed is bundled and we want to isolated from any user Python environment. However, it introduces an issue in some Linux distros, or at least Debian based ones, and maybe others too (and maybe even Windows, as it has the option to install packages in
%APPDATA%\Python
, but needs to be tested).In these Python environments
pip install
by default installs packages in the "user's environment" and so, they are not present to the interpreter when using the-I
flag.So when launching Mu and it tries to create a virtualenv with the
-I
flag it cannot find the module:To show this in a relatively clean Ubuntu 20.04, after running
python3 -m pip install mu-editor==1.1.0b7
, these are the packages locations:Basically anything from the OS is installed in
/usr/lib/python3/dist-packages
and everything installed by the user from thepip install mu-editor
command is in/home/parallels/.local/lib/python3.8/site-packages
.Using the
-I
flag we can see that the interpreter doesn't see any of the Mu dependencies:Crash reports: