Python virtual environments
Python virtual environments
Posted Jun 21, 2018 18:06 UTC (Thu) by raven667 (subscriber, #5198)In reply to: Python virtual environments by callegar
Parent article: Python virtual environments
Posted Jun 22, 2018 6:49 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
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.
Posted Jun 22, 2018 12:15 UTC (Fri)
by callegar (guest, #16148)
[Link] (1 responses)
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).
Posted Jul 3, 2018 1:24 UTC (Tue)
by ghane (guest, #1805)
[Link]
Python virtual environments
Python virtual environments
Python virtual environments
