3 ms·

Don’t do this… unless you have a very specific and non-standard usecase that requires it, like the author: > I work using git worktrees to have multiple branch

Don’t do this… unless you have a very specific and non-standard usecase that requires it, like the author: > I work using git worktrees to have multiple branches checked out at the same time. By using this trick, I can run different commands and make sure the imported package is from that branch, instead of having to python3 -m pip install -e . around all the packages For most usecases, you can wire up your imports and script entry points in poetry, and manage venvs there too. Or just use pyenv-virtualenv if you’re on MacOS to auto-use your per-project venv. Again, the author's requirements here are quite esoteric in my experience, and I’d really encourage folks to avoid this particular can of worms if at all possible.

opyate 3y ago
> if you’re on MacOS to auto-use your per-project venv. Just chuck the venv name into a .python-version file then pyenv will do that for you, on any OS.
polyrand 3y ago
Author here. I agree my setup is not simple (or even recommended as the default), that's why I call them "tricks". > you can wire up your imports and script entry points in poetry, and manage venvs there too. Or just use pyenv-virtualenv if you’re on MacOS to auto-use your per-project venv. As someone who has tried most of the current Python tools (including poetry and pyenv), I wouldn't say that "wiring up" imports and entry points is much simpler or footgun-free. It also requires using specific tools, which may not be possible depending on the project. Also, multiple venvs is not equivalent, since you still need to manage those venvs and install the packages (+ dependencies). The `PYTHONPATH` trick can save a lot of time when the dependency tree is complex, and you just want a single venv. For example, a workflow like: git worktree add -b feature_one # # edit some files # BRANCH=feature_one make run-service # in a different terminal, assuming `master` is also checked-out as a worktree BRANCH=master make run-service With the `PYTHONPATH` trick, you can do this in a few seconds. Now you have the same service running two different versions of your package, without having to reinstall anything or caring about using the correct venv. Again, I know this is a hack and it can be very project-specific. But it has worked great for me, and maybe it can be helpful to others.

opyate 3y ago

> if you’re on MacOS to auto-use your per-project venv. Just chuck the venv name into a .python-version file then pyenv will do that for you, on any OS.

polyrand 3y ago

Author here. I agree my setup is not simple (or even recommended as the default), that's why I call them "tricks". > you can wire up your imports and script entry points in poetry, and manage venvs there too. Or just use pyenv-virtualenv if you’re on MacOS to auto-use your per-project venv. As someone who has tried most of the current Python tools (including poetry and pyenv), I wouldn't say that "wiring up" imports and entry points is much simpler or footgun-free. It also requires using specific tools, which may not be possible depending on the project. Also, multiple venvs is not equivalent, since you still need to manage those venvs and install the packages (+ dependencies). The `PYTHONPATH` trick can save a lot of time when the dependency tree is complex, and you just want a single venv. For example, a workflow like: git worktree add -b feature_one # # edit some files # BRANCH=feature_one make run-service # in a different terminal, assuming `master` is also checked-out as a worktree BRANCH=master make run-service With the `PYTHONPATH` trick, you can do this in a few seconds. Now you have the same service running two different versions of your package, without having to reinstall anything or caring about using the correct venv. Again, I know this is a hack and it can be very project-specific. But it has worked great for me, and maybe it can be helpful to others.