I’ve been using pipenv for a good while but I’ve started to move over to venv slowly, and I like it so far. It’s a bit more of manual work but I feel like it’s worth it.
I love this workflow because it has only two prerequisites: python and pip. It works on windows, linux, any vm or container. Pipenv requires some setup, while this should work everywhere. In powershell you have to use ./.venv/bin/acticate.ps1 but that’s the only difference.
What did you not like on pipenv in comparison to venv? I was always avoiding venv because it was, as you said, manual work and it was too much effort to again google what was the order of commands and parameters to start a venv, which is not an issue in pipenv, since you just pipenv install what you need.
We had some issues in our CI where pipenv would sometimes fail to sync. It has recently gotten better, I think due to a fix of some race condition due to parallel installation. I think venv would be better suited for CI in general, since it allows the use of a simple requirements.txt file.
The other thing is I think it is rather slow, at least on windows which most of my team uses.
To conclude, I think as long as you aren’t having any trouble and it simplifies your environment, you might as well use it.
I only use python as a go-to scripting language when I need to quickly automate something or write a quick throwaway script that requires an SDK, since there’s a python library for almost anything and doing it in powershell would be too much aditional work. But it does make sense that for CI you only need to figure out the venv setup once and you’re done, so it may be a better solution.
My workflow:
cd project python -m venv .venv . ./.venv/bin/activate pip install -e .By default pyvenv excludes system packages, so I can have different versions in the venv. To reset the venv, I just have to delete the .venv dir.
I’ve been using pipenv for a good while but I’ve started to move over to venv slowly, and I like it so far. It’s a bit more of manual work but I feel like it’s worth it.
I love this workflow because it has only two prerequisites: python and pip. It works on windows, linux, any vm or container. Pipenv requires some setup, while this should work everywhere. In powershell you have to use
./.venv/bin/acticate.ps1but that’s the only difference.i’ve moved to just using conda environments. i find it’s a lighter load on my old brain.
What did you not like on pipenv in comparison to venv? I was always avoiding venv because it was, as you said, manual work and it was too much effort to again google what was the order of commands and parameters to start a venv, which is not an issue in pipenv, since you just pipenv install what you need.
We had some issues in our CI where pipenv would sometimes fail to sync. It has recently gotten better, I think due to a fix of some race condition due to parallel installation. I think
venvwould be better suited for CI in general, since it allows the use of a simplerequirements.txtfile.The other thing is I think it is rather slow, at least on windows which most of my team uses.
To conclude, I think as long as you aren’t having any trouble and it simplifies your environment, you might as well use it.
I only use python as a go-to scripting language when I need to quickly automate something or write a quick throwaway script that requires an SDK, since there’s a python library for almost anything and doing it in powershell would be too much aditional work. But it does make sense that for CI you only need to figure out the venv setup once and you’re done, so it may be a better solution.
I use pipenv and the workflow is essentially the same.
cd project mkdir .venv python3 -m pipenv shell pipenv install --devIt’s also nice because VScode (or VSCodium if you’re based), automatically detects it to set as your venv.
Seconded, after being burned repeatedly I always do this. But why are you calling activate from the directory above?
I don’t think he does. If you’re talking about the third line, there’s a space between the dots.
The dot command is equivalent to
source(running the script in the context of the current shell).Exactly, venv solves this issues for me