3 ms·
Very tangential, but wanted to share a small QoL trick that makes using poetry (and venv in general) much nicer... Instead of having to type "poetry shell" to
by tlonny 3y ago
Very tangential, but wanted to share a small QoL trick that makes using poetry (and venv in general) much nicer...
Instead of having to type "poetry shell" to activate the virtualenv, I use a tool called direnv that automatically modifies envars when you enter a directory - undoing the changes when you leave.
In my direnv config (.envrc) for the directory I write:
PATH_add .venv/bin
To add all the virtualenv executables to PATH. Now I can just call "python/pip" directly and never have to worry if I'm inside my virtualenv or not.
N.B. for this you need to update poetry config to ensure virtualenvs are placed in the project directory vs. the default centralised location
- PufPufPuf 3y agoIt's better to activate the virtualenv properly: . .venv/bin/activate Setting up just the PATH may confuse some tools.
- regularfry 3y agoI personally intensely dislike tools that change the environment based on the directory contents. I use an `exec` script in the root (or parent, sometimes) that just does this: ``` #!/bin/bash source .venv/bin/activate exec $SHELL $@ ``` That gives me a subshell with the virtual env active, and the path to the virtual env goes into $PS1 so I've got a very visible "you are working in this project" signifier. I don't know why subshells aren't more popular for this sort of thing, they remove a lot of ambiguity (and subsequent opportunities to screw things up) for me.