I have been using Makefile for over 10 years in all of my projects, and here are some features I've always found lacking in Makefile:
1. There is no way to display documentation for commands and accepted parameters. Yes, you can write a special task that will display comments, but you have to copy it from project to project.
2. The need to pass named parameters when calling tasks. I want to write `make serve localhost 3000` instead of `make serve bind=localhost port=3000`
3. I've always had the need in different projects to use the same commands, so I had to copy tasks from project to project. I need a central place with commands that I can apply to any project.
4. The ability to write tasks in different languages. In some cases, it's easier to write in Python or TypeScript/Deno.
5. And most importantly, it is difficult to write commands in Makefile that can be used in different environments. For example, I need to run commands on different groups of servers: production and staging. This could look like: `make production TASK1 TASK2` or `make stage TASK1 TASK2`. In other words, the production/stage task sets up the parameters for executing tasks in a specific environment. It might be possible to call commands in this way with Makefile, but it seems too complicated.
I think Just (as in Justfile) also solves most of your points, is reasonably widely used, also written in Rust and has integration plugins for it in most editors.
These “run something” targets should be marked as .PHONY so make realizes they will not produce a file. Otherwise a file named like the target will confuse make and turn your day into a sad one.
The main reason I still use Make over other alternatives is that everyone already has it. No need to install something else to bootstrap a project. I put in a `make initialize` that takes care of everything: setting up the virtualenv, using our internal pip mirror, downloading dependencies, etc. It's just such low friction!
Side note: Make is also really popular among self-hosters for ansible infrastructure setup.
Make wasn’t designed to be a task runner. It can be used as one, but it doesn’t make (pun not intended) a very good one, and it doesn’t have the best syntax, either.
Make is an artifact updater. Although it’s not its main focus, Peter Miller’s classical paper ‘Recursive Make Considered Harmful’ does a good job of explaining what it is.
One great benefit of make is that it’s present everywhere, so there’s no additional hassle of installing an extra tool. Depending on the project, this hassle-freeness may or may not outweigh make’s relative incomfort as a task runner.
What things were designed for is often a side show. We want to think that intent of creation matters, for some reason, when reality is full of that never really being the case.
So, on the merits, what makes it a bad task runner between outputs? I agree it is somewhat obtuse, but I'm still mostly crying from trying to get nox and a few other things working. Githubs workflow syntax is as painful, all told. (Though, it has the very real constraint that it is "per repository" and you need something above it.)
> ...there is no more important proposition for every sort of history than that which we arrive at only with great effort but which we really should reach, -- namely that the origin of the emergence of a thing and its ultimate usefulness, its practical application and incorporation into a system of ends, are toto coelo separate; that anything in existence, having somehow come about, is continually interpreted anew, requisitioned anew, transformed and redirected to a new purpose...
Well first of all if you’re not using any dependency tracking logic anyway it provides 0 advantages over some scripts like make.sh test.sh push.sh lint.sh (where test.sh can simply call make.sh if you want).
While poetry is the way to go today, I've got my eyes on pdm. https://github.com/pdm-project/pdm
Pyproject.toml is a pep standard so it will be easy to move around tools.
Very different. Requirements.txt only handles dependency packages, and only handles on kind of dependency (no dev/release distinction). pyproject.toml does dev/release deps, it has package metadata, it can configure all your lint/test tooling, and it is extensible with plugins.
I'm considering using it because the justfile can be anywhere in the directory tree above the point where you're running it. (This happens to be useful in certain situations like terraform env/region/stack trees. "Just" is also a command runner. While (as another person has pointed out) "make" is everywhere, "just" is easy to install.
as someone who maintains projects both using just and make, I have to say just is awesome, and allows things like writing a given task directly in a scripting language. sadly its not universally available across operating systems and linux distros (ubuntu/debian was the last significant dev ecosystem where it wasn't native, re apt install). so for projects with wider contributor goals, I still default to make, despite its warts (which are many imo), cause it tends to work ootb.
Makefiles are great for local task automation. In college I had a friend who started every homework, even the social science and English homework, with a makefile to compile his Latex files.
Readit News
1. There is no way to display documentation for commands and accepted parameters. Yes, you can write a special task that will display comments, but you have to copy it from project to project.
2. The need to pass named parameters when calling tasks. I want to write `make serve localhost 3000` instead of `make serve bind=localhost port=3000`
3. I've always had the need in different projects to use the same commands, so I had to copy tasks from project to project. I need a central place with commands that I can apply to any project.
4. The ability to write tasks in different languages. In some cases, it's easier to write in Python or TypeScript/Deno.
5. And most importantly, it is difficult to write commands in Makefile that can be used in different environments. For example, I need to run commands on different groups of servers: production and staging. This could look like: `make production TASK1 TASK2` or `make stage TASK1 TASK2`. In other words, the production/stage task sets up the parameters for executing tasks in a specific environment. It might be possible to call commands in this way with Makefile, but it seems too complicated.
As a result, I decided to write my own utility for task automation: https://github.com/devrc-hub/devrc
It solves all of the above problems and has other interesting features and also written in Rust .
After a short detour via just Ive been using a shell script with a big case statement since.
Side note: Make is also really popular among self-hosters for ansible infrastructure setup.
Make is an artifact updater. Although it’s not its main focus, Peter Miller’s classical paper ‘Recursive Make Considered Harmful’ does a good job of explaining what it is.
One great benefit of make is that it’s present everywhere, so there’s no additional hassle of installing an extra tool. Depending on the project, this hassle-freeness may or may not outweigh make’s relative incomfort as a task runner.
So, on the merits, what makes it a bad task runner between outputs? I agree it is somewhat obtuse, but I'm still mostly crying from trying to get nox and a few other things working. Githubs workflow syntax is as painful, all told. (Though, it has the very real constraint that it is "per repository" and you need something above it.)
https://python-poetry.org/docs/cli/#run