[KajMagnus]

Thanks for the reply & all info :- )

Actually, this: `USER=my_name make psql` and this: `make psql USER=my_name` I don't like that much: No command line completion of `USER=my_name`.

Makefile targets like `mycluster-kubie` are nice, although they can result in a combinatorial explosion (if one needs two or more parameters).

It seems to me that after all, it'll be Deno or maybe Rust "scripts" that I'll want to use, combined with Make — Make for building, and Deno for running things.

(Running = often, nice with command line completion. Building = less often.)

Thanks for the extra pieces of software :- ) Direnv looks nice, makes me nervous about security exploits though (seems it automatically parses a file in the current directory, sometimes provided by strangers, via a Git repo that maybe I just wanted to look at). Hmm, https://github.com/direnv/direnv/issues/23 "security considerations"

Git-crypt seems like a nice way to maybe distribute secrets for accessing one's CI environment :- )

Didn't know about entr. Currently I use inotifywait (from package inotify-tools in Debian)

[hardwaresofton]

No worries, no one really talks about it, but you see makefiles all over.

> Actually, this: `USER=my_name make psql` and this: `make psql USER=my_name` I don't like that much: No command line completion of `USER=my_name`.

> Makefile targets like `mycluster-kubie` are nice, although they can result in a combinatorial explosion (if one needs two or more parameters).

True, it's a bit inconvenient!

> It seems to me that after all, it'll be Deno or maybe Rust "scripts" that I'll want to use, combined with Make — Make for building, and Deno for running things.

This sounds wonderful -- the biggest downfall of make is when you start to try and do complicated things with it, so your usecase seems awesome. Make is good for that glue/orchestration in my opinion -- when you need to run pulumi/terraform right before you do some deno-scripted setup.

> Thanks for the extra pieces of software :- ) Direnv looks nice, makes me nervous about security exploits though (seems it automatically parses a file in the current directory, sometimes provided by strangers, via a Git repo that maybe I just wanted to look at). Hmm, https://github.com/direnv/direnv/issues/23 "security considerations"

Ahh so for that, I don't check in my `.envrc` folders but yeah that's certainly an issue -- whenever you encounter a `.envrc` you have to allow it though!

Every time you enter a folder that direnv hasn't seen before, or the file in there changes, you have to run `direnv allow` for it to be taken up.

> Didn't know about entr. Currently I use inotifywait (from package inotify-tools in Debian)

Ahh then that's probably just as good -- A friend showed me entr like.... 10+ years ago now and it's been a trusted tool on projects ever since, whenever the language/framework doesn't really have it, or I feel like some bit of work needs to be more streamlined/shorter feedback.

[KajMagnus]

> Every time you enter a folder that direnv hasn't seen before, or the file in there changes, you have to run `direnv allow` for it to be taken up.

That sounds great, just like I would have hoped that it'd work. And, because of this: "or the file in there changes", in a way it's even safer than a Makefile — in that Make wouldn't notify me if the Makefile got changed, but Direnv does (and people might not remember to look at any Makefile diff after pulling from the repo). — Now I'm starting slightly thinking about if Direnv makes sense somewhere in my own project(s).