Python virtual environments

Posted Jun 21, 2018 7:55 UTC (Thu) by callegar (guest, #16148)
In reply to: Python virtual environments by flewellyn
Parent article: Python virtual environments

> Why is it bad to use pip to install systemwide packages?

Because python does not support versioned packages, never had.

So you cannot have on your system 2 different versions of the same package in the same way as you can have on your systems two different versions of e.g., a C library.

You cannot say anything like

import xxxyyyzzz as xyz at {versions}

from xxxyyyzzz at {versions} import abc

where versions is some version specifier e.g. ['>2.5.0', '<3.0.2']

so, when you pip install something you end up "hiding", or "breaking" another version of that same something that you may have already had installed (e.g. by your distro) and on which some part of your system may depend.

Not that this is not a problem that gets magically solved with virtual environments either. Virtual environments only mitigate it.

If you write program A that depends on package B, which in turns depends on C at version Y and then you realize that you also need D that also require D that depens on C at version Z, then you are in big trouble.

So the real question should probably be: "why does not python support versioned packages"?

Python virtual environments

Posted Jun 21, 2018 18:06 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

Honestly, this is one reason why containers exist, why solve this problem individually and separately for every different kind of language/runtime when you can solve it systematically at the OS level once for everything.

Python virtual environments

Posted Jun 22, 2018 6:49 UTC (Fri) by marcH (subscriber, #57642) [Link]

Clear Linux has a single version number for the whole system.

Source code used to be versioned file by file. Git and others made the single version number popular. Then submodules and repo stroke back.

Etc. Modularity is *hard* and what goes around comes around.

Python virtual environments

Posted Jun 22, 2018 12:15 UTC (Fri) by callegar (guest, #16148) [Link] (1 responses)

For instance, because containers, just like virtual environments (that may be seen as a lower form of containerization) only mitigate the issue, do not solve it.

As mentioned before if you write program A that depends on package B, which in turns depends on C at version Y and then you realize that you also need D which depends on C at version Z, then containers or virtual environments are not going to help.

But what I find weird is that versioned "libraries" or "packages", that is a simple solution that was invented together with shared libraries many tens years ago, which would cost very little to implement in a high level interpreted language and which would not preclude at all the use of containers or virtual environments did not make into Python that, for other things, does not seem to completely avoid rather complex solutions and their associated cost.

The funny thing is that the very language developers feel the need to introduce "naming" conventions to work around this limitation (e.g., because versioned packages do not exist, they end up attaching the major version number to the package name itself as in urllib vs urllib2). Same goes for extension packages on Pypi (e.g., gmpy vs gmpy2).

Python virtual environments

Posted Jul 3, 2018 1:24 UTC (Tue) by ghane (guest, #1805) [Link]

... and python2 and python3 :-)