Pyenv seems to be the defacto python version manager, and Pipenv seemed to integrate well with it. Why has the python tooling community moved away from it?
I wrote an alternative that has 0 overhead called rtx. https://github.com/jdxcode/rtx
Generally speaking you'll probably want to use `rtx activate` in your shell rc. However you could use the shims instead if you just wanted to add a directory to PATH instead.
Of course you'd be getting rid of one of the major selling points of rtx by using shims, but it's so much faster than asdf the shims aren't as bad as they are in asdf.
I could see some projects not being interested in automatically installing versions using Pyenv. But I think most projects wouldn't mind the option to defer to Pyenv before searching PATH, or to otherwise configure a custom Python search path that could be derived from Pyenv and/or other sources.
Note that Pyenv is itself basically a pile of shell scripts, and it doesn't work on Windows (although there is a Windows port of it). There might also be a general expectation that this functionality is too complicated to support in a way that makes everyone happy, and that users need to figure it out on their own, e.g. using the technique described in the article here.
You can also go the other way and use the Pyenv-Virtualenv plugin.
It is a concern for library producers but they are definitely the minority.
My uninformed guess is that Guido didn't consider how to install anything to be part of the language so it didn't get much scrutiny.
Python is a huge ball of yarn comprised of donations of, perhaps hundreds individual developers w/o strong ties to each other. If you look inside the project, you find plenty of distinct styles and approaches coexisting and overlapping. The moderation is very weak / non-existent.
Installation utilities, however, were in Python since very early on. "distutil" dates back to, probably, one of the first public releases. It's since then was always part of the "standard" library, but it's going to be removed in the name of chaos, anarchy and entropy in one of the upcoming releases.
There was never any great design in Python in general, or in distutil in particular, but through a series of bad decisions, which were quickly carved in stone, we ended up with the system we have today. Setuptools was a first community project which grew out of recognition of inadequacy of distutil, but, instead of trying to replace it, it was designed to be a drop-in replacement in terms of interface and was made to depend on distutil in order to do anything useful.
This result in setuptools being a lot more convoluted and rigid than desired. Few people wanted to participate in this project, and so it was proclaimed dead several times, setuptools2 was supposed to replace it etc... but the decisions carved in stone wouldn't allow anyone to really dislodge it.
Gradually setuptools grew more hair, another pair of horns and wings by merging with distribution, easy_install, resouces_pkg and a bunch of other smaller evils, making itself ever more indispensable. Somewhat in parallel to that process, pip was starting to pick up speed. Pip promised a lot, but never delivered on those promises (eg. setuptools was never able to uninstall packages, while pip has "uninstall" command, it's broken by design).
And then anyone who made any sense abandoned Python. Python community was left with Python Foundation people or PyPA in this instance, who are not competent to deal with packaging. The entire activity today around packaging in Python may be described as chaos. It's adding random features based on the assumption that existing features work when they don't. Trying to get rid of the only useful tools while replacing them with tools that rely on the tools being replaced etc. It reads like some sort of an absurdist novel if you have to dive deep into it. And yet, it's a technology used by millions, shuffling trillions of goods and services around the world...
And are all your up-voters serious, too?
Learn your shit, dude! Because right now, your shit owns you.
What that document confirms is that at one point, when Python was cool, and people liked to talk about Zen Buddhism (probably inspired by Hofstadter's book), someone, semi-jokingly wrote that PEP. And this is all there is to it... You cannot be possibly delusional enough to think that eg. "explicit is better than implicit" is somehow provable or enforceable or can even be properly defined... Like, a lot of Python programmers would agree that context managers do implicit state management or that, in general, decorators create implicit behaviors attached to code of the functions or classes they decorate... and yet Zen of Python PEP still exists, right? So, what makes you think it's some sort of a rule that's never broken by the language it's allegedly applied to?
Nobody wants to support something that can turn even the simplest ticket into a game of cluedo.
The proliferation of useless tools that advertise themselves as solutions to unnecessary problems created by the core of Python development simply shouldn't be happening. If Python community wants to overcome the ridiculous state it's in right now, it needs to concentrate on fixing the problems at their core, not on creating another layer of duct tape around the rotten core.