3 ms·

I hate python package management - I really do. But I've never actually had a problem with virtual environments, and I think it's because I just use virtualenv

I hate python package management - I really do. But I've never actually had a problem with virtual environments, and I think it's because I just use virtualenv directly (rather than conda or whatever else). I have these aliases in my .bashrc, and I can't remember the last time I had a major issue. alias venv='rm -rf ./venv && virtualenv venv && source ./venv/bin/activate' alias vact='source ./venv/bin/activate' alias pinstall='source ./venv/bin/activate && pip install . && pip install -r ./requirements.txt && pip install ./test_requirements.txt' I don't have all the fancy features, like automatically activating the virtualenv when I cd into the directory, but I've always found those to be a bigger headache than they are worth. And if I ever run into some incompatibility or duplicate library or something, I blow away the old venv and start fresh. It's a good excuse to get up and make a cup of tea.

Izkata 4y ago
> virtualenv venv That would be python2, in 3 it's "python -m venv venv" (first venv is package to run, second is directory to put it in) Otherwise yeah, it's the same and I also use it manually. Never had any problems.
- jvolkman 4y ago
  `virtualenv` still exists and is still actively developed. It's true that Python 3 ships with `venv` but I think `virtualenv` offers some additional features. https://github.com/pypa/virtualenv https://github.com/pypa/virtualenv
jimnotgym 4y ago
Agreed. I tried the new package manager combined with venv and using venv directly seems best. A lot faster for a start.
spprashant 4y ago
I might steal these aliases, thank you. Using virtualenv directly has also been my approach, and has not failed me yet. I also used Poetry for one of my personal projects, and I liked what I saw.
pottertheotter 4y ago
I use pyenv[1] and the pyenv-virtualenv[2] plugin and I've not had a problem. It's so easy. [1] https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv [2] https://github.com/pyenv/pyenv-virtualenv https://github.com/pyenv/pyenv-virtualenv
- Karrot_Kream 4y ago
  pyenv needs to have its shims in place by running the pyenv init. You can run it when your shell starts but I find it kind of slow and for a while it used to be wonky in fish. But once I run the init, pyenv does work. That's just for managing your python installation and virtualenv though. You still need to manage your packages and for that you have options like requirements.txt, pipenv (not pyenv lol), Poetry, and others.
danielvaughn 4y ago
A few weeks ago I spent about a week debugging my Poetry environment. Turns out, their latest release (which I believe was a patch bump!) brought in some breaking changes. And on top of that, a bunch of stuff was forcing python3.11 under the hood, whereas I was on python3.10. It was a nightmare.
- silverwind 4y ago
  Poetry seems to break compatibility with every release of either itself or Python, double the fun.
kgodey 4y ago
I use virtualenvwrapper[1] and can't remember any problems with virtual environments either. It sets up human readable aliases for you like "mkvirtualenv" to create a virtualenv and "workon" to activate a virtualenv. [1] https://github.com/python-virtualenvwrapper/virtualenvwrapper https://github.com/python-virtualenvwrapper/virtualenvwrappe...
rewgs 4y ago
This is similar to what I do, except my "new environment" alias executes a function that takes a python version, installed/specified via pyenv. Never had a single problem, venv + pyenv is a great combo. As far as I can tell, like so many sources of frustration in tech, the issue typically lies with user error/not fully understanding the tool you're using. That isn't saying that there isn't room for improvement -- most notably, package management in Python flies in the face of "there should be one -- and preferably only one -- obvious way to do it" -- but the tools we have work quite well.
albert_e 4y ago
I have struggled with conda and the huge space it usually eats up I should learn to use venv properly Thanks
Joker_vD 4y ago
> source ./venv/bin/activate To this day I'm not quite sure why the venv developers decided that sourcing was a good idea; all it does can be effectively replaced with #!/bin/sh export VIRTUAL_ENV="path to venv" export PATH="$VIRTUAL_ENV/bin:$PATH" unset PYTHONHOME exec "$SHELL" Just run this script to get into an "activated" shell. To deactivate, just press Ctrl+D. If you're really fancy, you can replace the last line with exec "${@:-$SHELL}" to run a command directly in the activated environment (and then deactivate it immediately).
- ElectricalUnion 4y ago
  This technique is simple, doesn't reinvent the wheel, and even has it's own name: Bernstein chaining. http://www.catb.org/~esr/writings/taoup/html/ch06s06.html http://www.catb.org/~esr/writings/taoup/html/ch06s06.html

Izkata 4y ago

> virtualenv venv That would be python2, in 3 it's "python -m venv venv" (first venv is package to run, second is directory to put it in) Otherwise yeah, it's the same and I also use it manually. Never had any problems.

jvolkman 4y ago
`virtualenv` still exists and is still actively developed. It's true that Python 3 ships with `venv` but I think `virtualenv` offers some additional features. https://github.com/pypa/virtualenv https://github.com/pypa/virtualenv

jimnotgym 4y ago

Agreed. I tried the new package manager combined with venv and using venv directly seems best. A lot faster for a start.

spprashant 4y ago

I might steal these aliases, thank you. Using virtualenv directly has also been my approach, and has not failed me yet. I also used Poetry for one of my personal projects, and I liked what I saw.

pottertheotter 4y ago

I use pyenv[1] and the pyenv-virtualenv[2] plugin and I've not had a problem. It's so easy. [1] https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv [2] https://github.com/pyenv/pyenv-virtualenv https://github.com/pyenv/pyenv-virtualenv

Karrot_Kream 4y ago
pyenv needs to have its shims in place by running the pyenv init. You can run it when your shell starts but I find it kind of slow and for a while it used to be wonky in fish. But once I run the init, pyenv does work. That's just for managing your python installation and virtualenv though. You still need to manage your packages and for that you have options like requirements.txt, pipenv (not pyenv lol), Poetry, and others.

danielvaughn 4y ago

A few weeks ago I spent about a week debugging my Poetry environment. Turns out, their latest release (which I believe was a patch bump!) brought in some breaking changes. And on top of that, a bunch of stuff was forcing python3.11 under the hood, whereas I was on python3.10. It was a nightmare.

silverwind 4y ago
Poetry seems to break compatibility with every release of either itself or Python, double the fun.

kgodey 4y ago

I use virtualenvwrapper[1] and can't remember any problems with virtual environments either. It sets up human readable aliases for you like "mkvirtualenv" to create a virtualenv and "workon" to activate a virtualenv. [1] https://github.com/python-virtualenvwrapper/virtualenvwrapper https://github.com/python-virtualenvwrapper/virtualenvwrappe...

rewgs 4y ago

This is similar to what I do, except my "new environment" alias executes a function that takes a python version, installed/specified via pyenv. Never had a single problem, venv + pyenv is a great combo. As far as I can tell, like so many sources of frustration in tech, the issue typically lies with user error/not fully understanding the tool you're using. That isn't saying that there isn't room for improvement -- most notably, package management in Python flies in the face of "there should be one -- and preferably only one -- obvious way to do it" -- but the tools we have work quite well.

albert_e 4y ago

I have struggled with conda and the huge space it usually eats up I should learn to use venv properly Thanks

Joker_vD 4y ago

> source ./venv/bin/activate To this day I'm not quite sure why the venv developers decided that sourcing was a good idea; all it does can be effectively replaced with #!/bin/sh export VIRTUAL_ENV="path to venv" export PATH="$VIRTUAL_ENV/bin:$PATH" unset PYTHONHOME exec "$SHELL" Just run this script to get into an "activated" shell. To deactivate, just press Ctrl+D. If you're really fancy, you can replace the last line with exec "${@:-$SHELL}" to run a command directly in the activated environment (and then deactivate it immediately).

ElectricalUnion 4y ago
This technique is simple, doesn't reinvent the wheel, and even has it's own name: Bernstein chaining. http://www.catb.org/~esr/writings/taoup/html/ch06s06.html http://www.catb.org/~esr/writings/taoup/html/ch06s06.html