> - A cohesive, self-contained, easy to use, all-inclusive toolset, The only complex thing about Python packaging is that is separates it tools into "frontend"

> - A cohesive, self-contained, easy to use, all-inclusive toolset, The only complex thing about Python packaging is that is separates it tools into "frontend" and "backend" build tools. On the frontend, pip is essentially the cohesive, self-contained, easy to use, all-inclusive solution, as long as your backends support the standards [0][1]. > with a completely standardized manifest format for packages That's wheel [2]. Everything else is deprecated now, except for sdist (which doesn't really matter as it's limited to Python-only packages, and transparently supported by all tools). > And, for all that is holy, doesn't mess with the global environment so that we have to lie to it with virtual environments. This would be nice, but it is completely out of hands of the language developers. Different Linux (and other OSs, like OSX) distributions have made different decisions about the python version(s) they bundle by default, and in many cases the bundled versions are critical for some OS-level tools to function properly. Pretty much all interpreted languages either a) have their versions of virtual environments, or b) rely on a single system-wide interpreter. That being said, there is no need to use virtualenvs if a) you know that you need only one version of Python, and b) you have full control over your system. The best example is service deployments, where you can install a version of your choosing (or start with an appropriate base image), and install everything else on top of it. > That toolset would have to get overwhelming adoption by the community, to where it retroactively becomes The Python Package Manager (outside of legacy codebases, which would continue to languish). This would probably require endorsement by the Python developers Why exactly? There are two ways one can work with packages: 1. The majority of users want to be able to install packages. This is already the case. Pip is overwhelmingly adopted by everyone, with two notable exceptions: * Conda, which is mainly used in some niche sub-communities, and which is fully compatible with pip anyway * Build tools being used for installing packages, either during development or for deployment in very controlled environments But both of these exceptions are very specific and narrow in scope. > Otherwise we'll continue to have: https://xkcd.com/927/ https://xkcd.com/927/ We already don't have that situation. I agree that we did, but the standards are now very clear, and the tools are slowly moving in the right direction. [0] https://peps.python.org/pep-0518/ https://peps.python.org/pep-0518/ [1] https://peps.python.org/pep-0660/ https://peps.python.org/pep-0660/ [2] https://realpython.com/python-wheels/ https://realpython.com/python-wheels/