Several years in ops in a large company where I had to hand-hold couple hundreds of programmers a lot of whom needed to install Python for development on their

Several years in ops in a large company where I had to hand-hold couple hundreds of programmers a lot of whom needed to install Python for development on their computers... One of the troubleshooting steps when "something mysterious" happens on developer's computer (eg. package installation fails for inexplicable reasons, Python "standard" library components missing or present when shouldn't be, incorrect component version etc.) was to remove pyenv. This step was often met with resentment and arguments... but, in most cases I was able to win :) ---- Now, here's a larger point: some programs solve the problem by actually solving the problem, while other programs solve the problem by adding more code around the problem, which, usually, creates new problems while only partially solving the original problem. An example of the former: fsck -- you run it, it looks at your filesystem, tries to fix it, if it's broken and then gets out of the way entirely. An example of the later: Kubernetes -- you start by having a problem of resource allocation / management and you end up with a problem of resource allocation / management compounded by problems with component version management, configuration management etc. pyenv falls into the second category of programs. The problem it's trying to solve is: install and use multiple versions of Python. There's really no need for an extra helper program to solve this problem. Multiple versions of CPython can be installed and used together without the use of any extra tools. I.e. the solution to this "problem" is simply to learn how to do that. Those who advocate for the use of pyenv and the likes usually make an argument for "simplicity". I.e. in their mind, not needing to know how to install multiple versions of Python is a bonus. Something that, potentially, saves them several hours of reading the documentation and perhaps saving them a tiny bit of typing when setting up Python initially. I contend that this calculation is off because it doesn't account for the problems down the lane. In other words: pyenv helps until it doesn't, and then it becomes a liability. Debugging is always more difficult if you have more wrappers between you and your problem. So, while individual users will not face a lot of problems with "wrapper solutions", those who service such users will face such problems a lot more frequently. That's why, as an ops person, I really dislike "wrapper solutions" -- for me, they complicate the task, never help.