3 ms·

>Using virtual environments with pip, instead of installing packages system-wide, has been the recommended practice to avoid conflicts with OS-installed package

>Using virtual environments with pip, instead of installing packages system-wide, has been the recommended practice to avoid conflicts with OS-installed packages for quite some time. But it is not generally mandatory, so users sometimes still run into problems. I use virtualenv any time I use Python. That said, it would make way more sense if OS-installed packages used virtual environments, so that a user can pip install whatever they want on the default python install and not have to worry that it could bork dnf or any other system utility.

chriswarbo 5y ago
There shouldn't be a "python install" at all, let alone a "default". Whether an application uses this-or-that Python interpreter, or Ruby/Bash/Scheme/whatever should make about as much difference as whether a C program was compiled with GCC or Clang: it's an implementation detail, which doesn't need to be co-ordinated with everything else on the OS (although the package maintainers may want to coordinate, e.g. to allow re-use of files via soft-/hard-links, bind-mounts, etc.). When I "install foo-1.0 into my python environment", that's an annoying implementation detail (which is also imperative and non-atomic, i.e. there is a time where the python environment exists without foo-1.0). What I really want is "run a 'python' command where 'import foo' will have foo-1.0". That shouldn't break other applications which just-so-happen to use foo-0.5, or whatever.
uranusjr 5y ago
This is similar to the static vs dynamic linking debate. It’s easiest to deploy things if they are all self contained, but Linux distros have a strong tradition of dynamic linking and really don’t want to have (say) two separate paycopg2 installations if they can be shared. And once there’s a place to share stuff, users are going to inject new stuffs into it and give the package manager all sorts of trouble.

chriswarbo 5y ago

There shouldn't be a "python install" at all, let alone a "default". Whether an application uses this-or-that Python interpreter, or Ruby/Bash/Scheme/whatever should make about as much difference as whether a C program was compiled with GCC or Clang: it's an implementation detail, which doesn't need to be co-ordinated with everything else on the OS (although the package maintainers may want to coordinate, e.g. to allow re-use of files via soft-/hard-links, bind-mounts, etc.). When I "install foo-1.0 into my python environment", that's an annoying implementation detail (which is also imperative and non-atomic, i.e. there is a time where the python environment exists without foo-1.0). What I really want is "run a 'python' command where 'import foo' will have foo-1.0". That shouldn't break other applications which just-so-happen to use foo-0.5, or whatever.

uranusjr 5y ago

This is similar to the static vs dynamic linking debate. It’s easiest to deploy things if they are all self contained, but Linux distros have a strong tradition of dynamic linking and really don’t want to have (say) two separate paycopg2 installations if they can be shared. And once there’s a place to share stuff, users are going to inject new stuffs into it and give the package manager all sorts of trouble.