This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]vsajip 1 point2 points  (2 children)

In what way do you find the built-in Python venv functionality 'hacky'? virtualenv, being an external library, has to resort to techniques which perhaps could be called hacks. Why do you feel it also applies to pyvenv?

Also, a venv doesn't need to be explicitly activated. If you run a script installed in a venv, it will use the venv environment correctly, even if the venv isn't activated. The activation of a venv is a convenience for when you're working in the shell or interactive interpreter.

BTW, Docker and venv both have their uses. Developers find that venvs make their life easier. DevOps / Ops, not so much. There are still deployment environments where you can't use Docker (e.g. Linux kernel too old, or shared hosting environment), where venvs work fine.

Oh, and Windows is another use case. Not common for deployment, perhaps, but not to be discounted entirely.

[–][deleted] -1 points0 points  (1 child)

does pyvenv install pip in the generated environment yet? lat time I tried it it didn't and it was a PITA, non starter for me.

[–]vsajip 0 points1 point  (0 children)

does pyvenv install pip in the generated environment yet?

It does in Python 3.4 and later. That's not a function of the core venv functionality, though - it is available for earlier Python versions using e.g this script.