Hahaha!..
Oh shit, you’re serious.
It’s all fun and games until the wheel variant you need for your hardware acceleration package conflicts with that esoteric math library you planned on using.
This is the real answer to this question. Not just an invention to unfairly evaluate folks (and charge them originally to see it!), but nothing more than a “how much we can fleece you for” score that has become so widely embraced you can’t ignore it.
Let’s not forget HP making an “update” that effectively self-destructed the printer for use if you don’t use their cartridges. Evem after the public outcry and back pedaling by the company with a new bios update, my printer still “manifested” the same problem they intentionally introduced.
Replaced parts, tried other things, then just said “forget it” and replaced it with a more expensive color laser from a competitor. Happiness and reliable printing ensued.
Friend, while I appreciate the time and effort on the docs, it has a rather tiny section on one of the truly worst aspects of pip (and the only one that really guts usability): package conflicts.
Due to the nature of Python as an interpreted language, there is little that you can check in advance via automation around “can package A and package B coexist peacefully with the lowest common denominator of package X”? Will it work? Will it fail? Run your tool/code and hope for the best!
Pip is a nightmare with larger, spawling package solutions (i.e. a lot of the ML work out there). But even with the freshest of venv creations, things still go remarkably wrong rather quick in my experience. My favorite is when someone, somewhere in the dependency tree forgets to lock their version, which ends up blossoming into a ticking time bomb before it abruptly stops working.
Hopefully, your experiences have been far more pleasant than mine.