> Imagine the ease of a single ".targz" or so that includes the correct python version, all pips, all ENV vars, config files, and is executable. If you distribute that - what do you still need pip for?
pip is there so you don't need to do that. In the deployment world, you really want one version per system for everything and know that everything is in sync. To get that the solution was a distribution of software and a tool to manage them. We then extended that to programming language ecosystem and pip is part of the result.
But for workstation, a lot of people wants the latest, so the next solution was to be able to abstract the programming language ecosystem from the distribution (And you may not have a choice in the case of macOS), so what we get is directory-restricted interactions (go, npm,..) or doing shell magic so that the tooling think it's the system (virtual env,...).
It's a neat trick, but the only reason to do so is if you want to distribute compiled version of a software to customer. But if the user have access to the code, It's better to adapt the software to the system (repositories, flatpak...) or build a system around it (VM, containers, ...).
pip is there so you don't need to do that. In the deployment world, you really want one version per system for everything and know that everything is in sync. To get that the solution was a distribution of software and a tool to manage them. We then extended that to programming language ecosystem and pip is part of the result.
But for workstation, a lot of people wants the latest, so the next solution was to be able to abstract the programming language ecosystem from the distribution (And you may not have a choice in the case of macOS), so what we get is directory-restricted interactions (go, npm,..) or doing shell magic so that the tooling think it's the system (virtual env,...).
It's a neat trick, but the only reason to do so is if you want to distribute compiled version of a software to customer. But if the user have access to the code, It's better to adapt the software to the system (repositories, flatpak...) or build a system around it (VM, containers, ...).