There are several independent problems here:

1. Very short release cycle. This is independent of the Python venv
module but is indirectly influenced by Python's own release cycle.
Package maintainers don't have time for proper testing, they are
encouraged to release a bunch of new (and poorly tested) versions, and
they never get a break. So, when you install the latest, there will be
something else broken. There's never a window to properly test
anything.

2. Python made a very short-sighted decision about how imports work.
Python doesn't have a concept of "application", and therefore there's
no way to specify dependencies per application (and imports import
anything that's available, not versioned). That's why every Python
application ends up carrying its own Python, with the version of its
own dependencies around. Python's venv module is just an
acknowledgement of this design flaw. I.e. the proper solution
would've been a concept of application and per-application dependency
specification, but instead we got this thing that doesn't really work
(esp. when native modules and shared libraries are considered), but it
"works" often enough to be useful.

3. The Python community grew to be very similar to what PHP 4 was,
where there were several "poisonous" examples, which were very popular
on the Web, which popularized a way of working with MySQL databases
that was very conducive to SQL injections. Python has spread very bad
ideas about project management. Similar to how PHP came up with
mysql_real_escape() and mysql_this_time_promise_for_real_escape() and
so on functions, Python came up with bad solutions to the problems
that had to be fixed by removing bad functionality (or, perhaps,
education). So, for example, it's very common to use requirements.txt,
which is generated by running pip freeze (both practices are bad
ideas). Then PyPA came up with a bunch of bad ideas in response to
problems like this, eg. pyproject.toml. In an absurd way very much
mirroring the situation between makefiles and makefiles generated by
autotools, today Python developers are very afraid of doing simple
things when it comes to project infrastructure (it absolutely has to
be a lot of configuration fed into another configuration, processed by
a bunch of programs to generate even more configuration...) And most
Python programmers don't really know how the essential components of
all of this infrastructure work. They rely on a popular / established
pattern of insane multi-step configuration generation to do simple
things. And the tradition thus developed is so strong, that it became
really cultish. This, of course, negatively contributes to the overall
quality of Python packages and tools to work with them.

Unfortunately, the landscape of Python today is very diverse. There's
no universally good solution to package management because it's broken
in the place where nobody is allowed to fix it. Commercial and
non-commercial bodies alike rely on people with a lot of experience
and knowledge of particular Python gotchas to get things done. (Hey,
that's me!) And in different cases, the answer to the problem will be
different. Sometimes venv is good enough. Other times you may want a
container or a vm image. Yet in a different situation you may want a
PyPA or conda package... and there's more.

On Sun, May 19, 2024 at 4:05 PM Piergiorgio Sartor via Python-list

On 2024-05-19 at 18:13:23 +0000,
Package Installer for Python

https://pip.pypa.io/en/stable/index.html

Every time I see PIP, I think Peripheral Interchange Program, but I'm
old.

[snip]
From https://pip.pypa.io/en/stable/:

"pip is the package installer for Python."

It's an acronym.

On 2024-05-19 at 18:13:23 +0000,
Package Installer for Python

https://pip.pypa.io/en/stable/index.html

I always assumed it was in honor of the PIP (Peripheral Interchange
Program?) utility that was used to copy files around on CP/M and DEC's
PDP-11 OSes.

--
Grant

Of course, I'm not here to tell you how to use your computer, and it's
great that you're using Linux, but I'd suggest that you look into
installing Arch Linux proper.

Arch Linux isn't as difficult as people make it out to be (I'd argue
that anyone who's had to deal with the Calamares installer has seen
worse), and it's hugely rewarding as it gives you a fundamental overview
of how your system operates and what makes it tick, since you need to
install it yourself manually.

Plus, Manjaro holds back packages by about a month or so, sometimes
more, which breaks AUR packages, which are designed around Arch Linux's
packages, which are newer. On top of this, the Manjaro team just can't
be trusted with basic things like not having their SSL certs expire on
their website (this has happened half a dozen times in the past, which
is embarassing, given that things like certbot make installing a
certificate the easiest thing in the world).

Again, I'm not some power hungry elitist Arch Linux shill or whatever,
it's your computer, use it how you want, these are just my suggestions.
Don't say I didn't warn you though :)