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.
Makefile Tricks for Python Projects
31–35 of 35 posts
Re: Makefile Tricks for Python Projects
#32Earlier quoted context omitted.
Looks like it’s pretty much abandoned: > doit is under active development. Version 0.36.0 released on 2022-04.
Below what you quoted > doit core features are quite stable. If there is no recent development, it does NOT mean the project is not being maintained... The project has 100% unit-test code coverage.
Okay, but support stops at Python 3.10. I have nothing against the tool - it looks interesting. But isn’t support of current versions of Python table stakes for a tool like this? How am I, as a potential user of this tool, supposed to interpret the lack of 3.11 support and a last release dated end of last year?
Re: Makefile Tricks for Python Projects
#33 > 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.
Re: Makefile Tricks for Python Projects
#34Earlier quoted context omitted.
There’s a problem hidden. MacOS make is outdated (or not GNU flavor not sure) and, for example, doesn’t support parallel tasks by default or some more advanced recipes. Asking people to use gmake on a standard Makefile is much more difficult than just asking to install Justfile runner.
100% agree, and this bothers me a lot. I like `just`, but for some reason I keep coming back to `make`. > or not GNU flavor not sure On my macOS laptop which make # /usr/bin/make /usr/bin/make --version # GNU Make 3.81 > doesn’t support parallel tasks by default I haven't verified this. I've checked `make --help` using the built-in make on my Mac (GNU Make 3.81), it mentions the `--jobs` option to run multiple jobs i…
Checking the GNU Make manual it might me .NOTPARALLEL flag that wasn’t recognized correctly.
Cannot provide precise issues with (as it was more then a year) but I encountered 3-4 problems after having complete Makefile which was kind of downer because I had to rewrite it to support “vanilla” make.
In the end I dropped parallel went with Justfile and it took fraction of time (but truth be told I had dynamic PHONY targets which aren’t super easy to setup in Make).
Re: Makefile Tricks for Python Projects
#35Earlier quoted context omitted.
Below what you quoted > doit core features are quite stable. If there is no recent development, it does NOT mean the project is not being maintained... The project has 100% unit-test code coverage.
Okay, but support stops at Python 3.10. I have nothing against the tool - it looks interesting. But isn’t support of current versions of Python table stakes for a tool like this? How am I, as a potential user of this tool, supposed to interpret the lack of 3.11 support and a last release dated end of last year?
After the chaos of Python 2to3, backwards Python's backwards compatibility has been amazing. The tool is created for developers and claims 100% code coverage. Determining if it works with any specific version of Python would be a trivial exercise of clone the repo, make an venv, and run the tests.
This is something that a dev should do when evaluating a new dependency even when it claims to support the version relevant to you. Sadly, many do not.