3 ms·

You are partially right. Distros like Debian/Ubuntu used Python 2 extensively as a system dependency and so replacing /use/bin/python became a big undertaking.

You are partially right. Distros like Debian/Ubuntu used Python 2 extensively as a system dependency and so replacing /use/bin/python became a big undertaking. But since at least 2009 it was easily possible to install alternative versions and use them with virtualenv. pyenv has made it even easier since then and it made it platform agnostic.

PaulHoule 6y ago
I use virtualenv all the time, its great. Yet no matter how much I try to educate users some of them still feel entitled to use the system Python and I find it disheartening to try to suppport those people.
- einpoklum 6y ago
  I wonder if it would have helped to move the executable from /usr/bin/python to /usr/sbin/python . Or /usr/sbin/python-for-distro-use-only-dont-run-apps-with-this ...
  - anon19087 6y ago
    This is precisely what they did in RHEL 8: /usr/libexec/platform-python
- IgorPartola 6y ago
  It would be nice if virtualenv type of functionality was just a first class citizen for Python. Basically if you could just specify the root of your project and have ./site-packages/ automatically included in the path or similar. Yes of course you can just update sys.path but it would be neat to do that with no code necessary. Or do it with a config file like how PlatformIO does library management.
- nyanpasu64 6y ago
  On KDE, only system-installed PyQt5 has the Breeze theme. Pip-installed PyQt5 has a non-native theme and the resulting apps look out of place. There are ways to get virtualenv, pip, pipx, etc. to use system packages and only install local packages for those not present in the system.