You just want to install sphinx via pip in the virtual environment
too. Each venv should be atomic and isolated which means not
depended to system packages.
On 2023-03-03 18:44:19 +0000 (+0000), Danial Behzadi دانیال بهزادی wrote:
You just want to install sphinx via pip in the virtual environment
too. Each venv should be atomic and isolated which means not
depended to system packages.
However a venv can be made to use system packages if you use the --system-site-packages option when creating it.
--
Jeremy Stanley
Would it be hard to support both philosophies?[...]
I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that users with root privilege can modify by editing a config file (probably somewhere in /etc) and that would enable using pip outside a virtual environment, both as root and as regular user respectively.
I feel this would satisfy the needs of regular users to be protected
against accidentally breaking their system while enabling power users to
have full control of their computer and enjoy the simplicity of a single environment. Clearly this discussion suggests that debian has both types of users and we should support them both if we can.
Hello,
I recently reported
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032283 , and Dmitry suggested discussing it on this mailing list.
Virtual environments work by adding some version of Python (possibly just a symlink to the system one) at the beginning of PATH. Debian policy for
Python scripts is to use #!/usr/bin/python3 and **not** #!/usr/bin/env python3, so they are not affected.
I think there are 2 types of Python scripts. The first type is applications for end users, like hg or calibre (it is possible that the existence of plugins makes my choice of examples a bad one). If I have some strange
Python virtual environment active, I am happy that the Debian policy
prevents the virtual environment from breaking those applications (although
I may still be able to break them with PYTHONPATH).
I did not know about `sudo pip install --break-system-packages[...]
foo` or `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly
I only knew about this issue what I have read on this discussion).
On 2023-03-03 15:29:09 -0500 (-0500), Jorge Moraleda wrote:
Would it be hard to support both philosophies?
I would like to suggest a couple of configuration options that by default disallow using pip outside a virtual environment but that users with root privilege can modify by editing a config file (probably somewhere in/etc)
and that would enable using pip outside a virtual environment, both asroot
and as regular user respectively.
I feel this would satisfy the needs of regular users to be protected against accidentally breaking their system while enabling power users to have full control of their computer and enjoy the simplicity of a single environment. Clearly this discussion suggests that debian has both typesof
users and we should support them both if we can.[...]
"Power users" who like to break their systems can simply `sudo pip
install --break-system-packages foo` or even just `sudo rm /usr/lib/python3.11/EXTERNALLY-MANAGED` and then do whatever they
want anyway. It doesn't seem to me like there's much need for a
config option that does that for you, and adding one would imply
that Debian will help you fix things once you've done it. This
feature is simply a guard rail for users who otherwise wouldn't know
where the edge of that cliff is located.
There are already solutions for your power users, but as is often
said in such situations: If it breaks you get to keep the pieces.
Have fun!
--
Jeremy Stanley
Jeremy, Thank you for your quick reply!
I did not know about `sudo pip install --break-system-packages foo` or `sudo rm
/usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about this issue what I have read on this discussion). This is very helpful and it really changes
my outlook on this topic.
On Fri, Mar 03, 2023 at 04:22:11PM -0500, Jorge Moraleda wrote:
Jeremy, Thank you for your quick reply!
I did not know about `sudo pip install --break-system-packages foo` or`sudo rm
/usr/lib/python3.11/EXTERNALLY-MANAGED` (Frankly I only knew about thisissue
what I have read on this discussion). This is very helpful and it reallychanges
my outlook on this topic.
The --break-system-packages option is noted in /usr/share/doc/python3.11/README.venv, and this file is mentioned in
the NEWS file for python3.11. The
/usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there; I personally think that having to type --break-system-packages every
time one installs a package via pip globally or on a per-user basis is
safer, as it reminds you that you run risks doing so.
Best wishes,
Julian
the NEWS file for python3.11. The
/usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 379 |
Nodes: | 16 (2 / 14) |
Uptime: | 84:33:06 |
Calls: | 8,091 |
Files: | 13,069 |
Messages: | 5,851,128 |