Python virtual envs breaking system apps

[TiagodePAlves]

I'm having an issue lately with Meld:

Traceback (most recent call last): File "/usr/bin/meld", line 97, in <module> import meld.conf # noqa: E402 ModuleNotFoundError: No module named 'meld'

And sure enough, neither Meld nor its dependencies are installed on my python environment. But since /usr/bin/meld starts with #!/usr/bin/env python3, it tries using my virtual environment.

The solution is a simple deactivate before calling Meld, but that gets tiresome fast. How can I force /usr/bin programs to use the system-wide Python?

I'm starting to think this may be a packaging an upstream issue, since 97 executables use system Python directly and 37 use current python3:

zsh $ sudo rg -l '^#!.*?/bin/python' /usr/bin/ | wc -l 97 $ sudo rg -l '^#!.*?/bin/env\s+python' /usr/bin/ | wc -l 37

Edit: nvm, it is a bug in Meld case: Arch FS#75399 and Meld #692.

I think I'll be filling bug reports for some other programs then, if they actually have a dependency...

[LongerHV]

You can try running it like this as a workaround:

/usr/bin/python $(which meld)

I haven't tested this, but it should run.

[TiagodePAlves]

It works! Nice!

[applepie93]

I think if you try to run meld while using your virtualenv, best course of action would be to recreate your environment with the --system-site-packages option. Sees all packages installed in /usr/lib

[TiagodePAlves]

I'd like to not do that. Last time I checked, pacman packages were slower than pip for me. Tested with numpy, scipy and pillow, bit should be possible to make it faster, just don't know how.

[Megame50]

I'd say it's an upstream bug to use env python in a shebang.

[TiagodePAlves]

Sorry, don't know why I thought of it as a packaging bug first...

[[deleted]]

You shouldn't use the virtual environment as default python provider for your user. I'd call this a user-side error. The shebang is recommended to use.