[neonihil]

Unpopular opinion: tools other than virtualenv are for people who do not understand how virtualenv works. On the other hand: people who do understand how virtualenv works, know it very well we: don’t need the other tools than virtualenv.

[anuragsoni]

virtualenv doesn't let you manage installations of different python versions. This is the problem that pyenv solves.

[neonihil]

IMHO it’s solved by installing different python versions using the OS package manager, like `dnf install python3.8 python3.9`, and then creating virtualenv using whichever version you need, like `virtualenv -p python3.9 venv`

[anuragsoni]

You'll be limited to whatever python version is packaged on the host operating system. pyenv can let you test against development versions of python if needed, or released of python that are either new enough (or old enough in some cases) that they aren't available on your operating system's package repositories.

[neonihil]

You can `make dist` on the python repo to build the rpm of whichever branch/commit you want to use. Pre-built ones are also available from nightly build. I still don’t know why you need a separate tool for that.

[fock]

And this is not a Python problem either. It's a general problem.

[tandav]

Do you mean venv which is part of standard library or virtualenv (separate library)?

[neonihil]

AFAIK venv is a subset of virtualenv brought into the standard lib around python 3.3.

I’m talking about the “full” virtualenv. This one: https://pypi.org/project/virtualenv/