Hacker News Reader

Comment by srvmshr | Hacker News Reader

Can you please explain the pyenv usecase a bit more? Let us say, I needed Py3.6 for something - I can just use virtualenv with appropriate flags to install 3.6 tooling. How does PyEnv help further.

I have read often pyenv helps maintain different version of python on same system. But if that is also possible by virtualenv/venv what am I missing?

View on HN

You're missing that venv and virtualenv can't do that: they can only create environments for your current Python interpreter, not arbitrary Python versions.

There's no flag that I'm aware of that makes venv install a different Python version than the one it was invoked with.

The --python flag for virtualenv will let you specify a different Python executable to use, but requires that executable to already be installed somewhere on the system.

Getting another python executable is normal the challenge though.

Not really. Not under OSX, brew makes this simple. Under Linux, worst case, you just download the source and compile it. (Not sure about Windows though.)

And pyenv is a wrapper around “downloading the source and compiling it”.

Brew makes this easy? Are you sure? I installed python 3.9 with brew and it’s magically become a 3.10 install by upgrading another package

The version pinning on brew certainly isn't great, but you can do:

> brew install python@3.9 python@3.10 python@3.11

> I can just use virtualenv with appropriate flags to install 3.6 tooling.

No. I have no idea where you got that idea.

> But if that is also possible by virtualenv/venv what am I missing?

That it's not possible? venv is literally just a module of the standard distribution. And while virtualenv can do a few more things (hence why it remains as an independent project), installing new pythons is not something it can do.

Virtualenv and venv can only create environments for previously installed python (especially venv as you create environments via the python you want to create an env for, it doesn't support creating an env on behalf of a different python than the one it's invoked through).

Oh, my apologies. I confused that with the conda --python flag. Much appreciated catching that.

Venv helps maintain separate virtual environments for a given python installation, but it won't actually install python. E.g. if you have Python3.6 installed venv can use it, but you can use PyEnv to install 3.7, 3.8, 3.9, ... Which venv can then use.

Basically Python team sat down to consider how they can make their deployment setup worse, and they came up with the idea to split packaging, dependency management, virtual environments/isolation, and Python version management to each need a different too, and then had different random projects make several tries at of each tool, all at more or less equivalent popularity...

I was told the opposite - that the current mess is because the “Python team” did not sit down to consider deployment setups at all.

Reply on news.ycombinator.com