camilomatajira

I have been using it for a while and it has been useful. One feature that I am still missing is to be able to stack PR across repositories. In other words, I want this stack to contains some PRs to the backend, some to the front, and some to ArgoCD in some specific order.

Make is one of my favorite tools, I believe the author built a simple and robust system. I have certain degree of envy.

I made something similar but with Ansible wrapped as an uv script. What I like about ansible is that it's higher level so I'm able to do complex modifications to my machine without having to write them myself and handle the errors myself because the community behind the tasks have already done it. The idempotency of ansible out of the box is also very nice.

Here is my ansible/uv-script project if someone is interested: https://camilo.matajira.com/?p=591

Could you please provides examples on how to do it? Specially given that the operating system calls dont return back the output of the command? Thx

This is very useful, though I would recommend using a Makefile instead. You will get a lot out of the box: completion in your shell, idempotency (in case you are interested), useful string interpolation, easy variables injection, etc.

You could keep the content of your bash functions close to intact by adding the ".ONESHELL:" target (and some \$).

Nice article, I love Make and your blog looks sharp. I would suggest to provide the beginner friendly version in which all the rules are hard coded, so that a beginner can profit and don't be freightened. And then, introduce the problem of needing to add rules by hand for each new dotfile, and then provide your solution using Make's builtins.

I also suggest putting the complete final version of the Makefile at then end, so I can copy it.

Regards,

Summary: So why bother with Ansible in 2025? Because it gives you interesting features out of the box:1) Idempotency, 2) Drift detection, 3) a really high level ‘language’. And because used with UV, Ansible can be used as a standalone ‘scripting’ ‘language’, with idempotency and drift detection, again out of the box. For certain tasks, those are killer features. Which tasks? Think for example installation of software; installation of tools; Developer Experience (DevEx) setup; CD part of a CICD pipeline; setup of CI ephemeral runners etc.

This is worth gold: """ Power Imbalance

In theory, GitOps is neutral. A robot pulls from Git and makes reality match. Everyone gets to review, and every change is versioned. Feels fair. Right?

But in practice, GitOps introduces a very specific kind of power dynamic: the gatekeeper pattern.

Most of the time, it’s the infra or platform team that sets up GitOps. They define the rules—how environments are structured, how approvals work, which tools are allowed. And once that system is live, every change has to go through them.

It sounds like collaboration. In reality, it’s almost always a one-way review.

A backend developer wants to change a config file. They need a review from someone on the platform team. A frontend dev wants to bump a service version. They open a PR. They wait. A product engineer wants to expose a new route for testing. Same story. PR. Wait. Fix a nit. Wait again.

But it doesn’t go the other way. It almost never goes the other direction.

Infra changes things, merges to main, the bot deploys it. No one outside the infra team is reviewing their changes. No one’s stopping their PRs with a comment. They own the system, and everyone else is a guest.

That’s not collaboration. That’s control. """

Completely agree with you. You can't be an economist and criticize current monetary policy. You will be labeled a crackpot, ostracized and have difficulty with grants. Grants from who? The same institution you'll be critizing in the first place.

Anki is dead because, after LLMs were introduced, people lost the incentive to learn at all.

Frankly, who wants to learn something the old way when you can ask an LLM to do it for you?

All this reminds me of my home country when the Ponzi schemes were at their highest point (2008). There were small and medium cities, were a sizeable percent of the population actually stopped working at all! Why? Because the ponzi schemes were promising up to 300% returns within 6 months! And the Ponzi schemes were actually delivering (so much that the banks actually pressured the government to intervene). So people put all the money in the ponzis and simply wait a bit to cash in part of their returns. No one opened their small grocery stores, nor small pubs, nor did anyone want to do chores or manual labor. Until everything collapsed.

<Make is a really powerful tool, with an expressive language that is quite esoteric with a bunch of idiosyncrasies (just like bash). > Agree

<"Well, Make is installed on everyones machine (....)"> It's not everywhere but almost.

<(Yet another idiosyncratic language that we have to deal with)> This is true. However, one has to choose its investments. I believe that Make is a powertool like awk, sed and bash, and despite its ideosyncracies, all of them have a positive ROI.

<Make is not a task runner, it's a build system.> I think a lot of confusion comes from having the wrong perspective on what Make actually is. From the Oreilly book on Make:

"It is important to understand that make is sort of two languages in one. The first language describes dependency graphs consisting of targets and prerequisites. The second language is a macro language for performing textual substitution. "

Make is a 1) language to express dependencies and a 2) language to template and do text substituion at a higher level than scripting languages; it's not a build system, though it's can be used as a tool to help compile C, C++ and possibly others langs. This gives you the ability to resolve simple or complex chains of dependencies by just specifying "target: prerequisities; recipe" and put variables everywhere to keep the code DRY and add conditional logic.

This means that Make shines in whatever follows the pattern "target: prerequisites; recipe" and that is almost all type of scripting! Including 'task runner' kind of jobs.

(In this sense, creating files out of files, and not recreating and existing file, is a "feature" but not the core of Make. )

Hence, when you say that it would be cool to be more bash-compatible I think Make provides a way (see the .ONESHELL target.)

The --list option, could be implemented with a really small awk script, and I also add some ASCII art.

Concerning the discoverability of rules, Make provides bash and zsh completion out of the box.

Parallel execution also works out of the box by adding the -J option.

Conditional logic could be added using "conditional processing directives" and with macro expansions.

Make indeed is really powerful, I would recommend everyone to checkout the Oreilly book on Make.

And again, I'm not trying to bash Just or Task. I'm trying to point out that only because a tool is new does not mean that is better than the old one.

Congratulations on you project, hope to have once a project as succesfull as yours. I would like to clarify that I don't mean to bash Task, just tired of critiques saying that Make is bad because is old, and Just and Task are better only because they are new.

I agree with you. Make has it's quirks, specially those builtin variables ($@, $<, etc), they are ugly but useful.

I read Just's readme the other day. Basically they say Just is better than Make because in Just all targets are phony by default (something you can make easily in Make). And because they provide a flag to list the targets (which you can make easily in Make). And because Make is to too complex to differentiate between = and := (which as an user almost always gives you the same result, even if you don't understand the difference). These are basically the reasons, which are not convincing for me.

Anyway, 26K people find

Make is still king in 2025. I don't understand why someone would use Just or Taskfile instead of Make. My only hypothesis is that people believe (erroneously) that whatever is new is automatically better than what is older.