Do you really need them? Any Linux offers a wide selection of versions and, if you NEED TO (unlikely) build it from source yourself (not difficult) it neatly installs under /usr/local/bin with an executable appropriately named. I actively dislike pyenv - it adds a layer of magic on top of Python that's just one more thing to reason about.
From there, you can `-m venv` your way into any version you want.
The only rule is not to mess with the Python environment provided by the system packages. You can't do it without sudoing pip, which should serve as enough warning you are going to break your toys.
On dependency managers, I can't see what's that much broken with pip. What are people trying to do that a `pip install` and `pip freeze` doesn't solve? Shameless plug: I made pip-chill to solve some things (including dependencies in requirements file and removing version numbers). It doesn't solve conflicts, which is kind of OK given it'd need some manual intervention anyway. It does what you tell it to, which helps to fix conflicts.
As for people confused about which interpreter and environment they are using, oh well... Know your tools. It's often helpful to distribute setup scripts that set up a virtual environment and all dependencies instead of just uploading something with lots and lots of dependencies (itself a bad idea, in any language) to PyPI. YMMV.
They help a lot when you're dealing with lots of projects where you really care about specific x.y.z release, not just x.y. Then having a common way to manage runtimes is great if you use a few of them.
In short, "asdf install" is way better than download-compile-install python x.y.z, download-compile-install node x.y.z, etc. then making sure the scripts you start actually use the right version.
This article seems well-informed, and may be helpful to some, but it does not fill me with confidence that I would be able to navigate the pitfalls of Python package installation successfully.
When using pyenv, I find it useful to install like this to make sure you’re getting a framework build (some libraries are incompatible with non framework builds)
Do you really need them? Any Linux offers a wide selection of versions and, if you NEED TO (unlikely) build it from source yourself (not difficult) it neatly installs under /usr/local/bin with an executable appropriately named. I actively dislike pyenv - it adds a layer of magic on top of Python that's just one more thing to reason about.
From there, you can `-m venv` your way into any version you want.
The only rule is not to mess with the Python environment provided by the system packages. You can't do it without sudoing pip, which should serve as enough warning you are going to break your toys.
On dependency managers, I can't see what's that much broken with pip. What are people trying to do that a `pip install` and `pip freeze` doesn't solve? Shameless plug: I made pip-chill to solve some things (including dependencies in requirements file and removing version numbers). It doesn't solve conflicts, which is kind of OK given it'd need some manual intervention anyway. It does what you tell it to, which helps to fix conflicts.
As for people confused about which interpreter and environment they are using, oh well... Know your tools. It's often helpful to distribute setup scripts that set up a virtual environment and all dependencies instead of just uploading something with lots and lots of dependencies (itself a bad idea, in any language) to PyPI. YMMV.