Don’t do this… unless you have a very specific and non-standard usecase that requires it, like the author:<p>> 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<p>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.<p>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.
Similar in spirit, I made a reusable Makefile for my Python projects: <a href="https://github.com/sio/Makefile.venv">https://github.com/sio/Makefile.venv</a><p>It's a shame that Python venv workflow is so opaque and unfriendly to new users that it requires extra automation tools.
There are quite a few things here that I've used for a few years with option projects at work - overall I like it.<p>A big part of that is due to an endless stream of people who couldn't be bothered to learn what a venv was or how to use it, but... yeah, that's what work is like sometimes. The makefile pretty much ended those issues, absolutely worth the effort put into it.
I recently discovered just (<a href="https://just.systems" rel="nofollow">https://just.systems</a>), a make alternative that’s much more ergonomic IMO, and have been using it in my personal projects. It’s task-oriented, not goal-oriented, so not a perfect replacement, but works well for my needs.
I prefer to stay in python, makefiles become very difficult to maintain. I use <a href="https://www.pyinvoke.org/" rel="nofollow">https://www.pyinvoke.org/</a>
<p><pre><code> > The reason to use $$(some-command) instead of the built-in function $(shell some-command) is that the expression will be evaluated every time it is called. [...] When using $(shell ...) the expression gets evaluated only once and reused across all the recipes.
</code></pre>
I don't think the last sentence is true. As long as you define py using = and not := it will be evaluated every time it's used.
I’ve used make like this in the past, it’s handy. But zsh auto suggestion obviates the extra maintenance IMO. I type the command one time and it’s in my history. So my common dev actions are more flexibly maintained by recency than editing a file.<p>You could say the Makefile also serves as a form of (not great) documentation.
I use Makefiles for managing multiple venvs for various jobs. For example running test and running in production have different requirements (no testing libraries). Or an environment for static analysis tools.
See also: "Automate your Python project with Makefile" <a href="https://antonz.org/makefile-automation/" rel="nofollow">https://antonz.org/makefile-automation/</a>