Enable jinja "strict undefined behavior", fix templates, improve reporting

[fasterthanlime]

Most likely we need to contribute back to minijinja2 to get proper tracking information for "undefined errors" because right now all we see is this:

[fasterthanlime]

Current state of this PR: the corresponding minjinja fix has landed in their main branch, but not in a point release yet, which means our dep now looks like this:

So I don't love that for us and this PR can probably wait for a new minjinja to land (releases seem regular)

---

BUT! it looks awesome and is very useful: I pulled in color-backtrace for coloring and filtering and this helps me at least (I'm curious to see what @mistydemeo and @duckinator think about it specifically) narrow down what's wrong almost immediately:

color-backtrace is awesome (and the big dependency here is backtrace, which we already have) and has a RUST_LIB_BACKTRACE=full mode that even shows you the Rust source code:

Even though I'd like to wait for a minjinja point release to drop, I'm gonna stack my other PRs on top of this one because, damn, that's good tooling.

[fasterthanlime]

Note 1: I've forced backtrace capture, even if you haven't otherwise exported RUST_LIB_BACKTRACE=1 because I consider this equivalent to a panic, it might happen in CI, we're telling our users to report it and when they do, we'll want as much info as possible.

---

Note 2: this PR also fixes the few instances of us violating "strict undefined behavior", minjinja is going to get a little legalistic on us — the only thing y'all need to know is that if it complains something like:

      undefined value (in installer/npm/run.js:4)
   ╭─[4:1]
 3 │ const { run } = require("./binary");
 4 │ {%- if bin %}
   · ─────────────
 5 │ run({{ bin }});
   ╰────

Then you need if bin is defined, and the reason this happens is usually because the field is defined something like this:

struct Blah {
    #[serde(skip_serializing_if = "Option::is_none")]
    pub bin: Option<String>,
}

But in the actual case of bin? it's because it's rendered without any "context/globals" object once, as evidenced later in the code:

cargo-dist/cargo-dist/src/backend/installer/npm.rs

Lines 89 to 93 in 33316c5

	// There's a run.js.j2 that we actually want to render once-per-binary, so remove this copy
	let run_js_path = Utf8Path::new(RUN_JS);
	files
	.remove(run_js_path)
	.expect("npm template didn't have a run.js!?");

ie. while "rendering the directory template", it gets rendered once with zero context, and then it's removed and re-rendered with the correct context. That's a hack and I hate it, but with just if bin is defined instead of if bin, we can go ahead anyway:

{%- if bin is defined %}
run({{ bin }});
{%- endif %}

[fasterthanlime]

After discussing in Discord, we'll publish minjinja as axominijinja and switch to that for the next release, then switch back when it's done.

[fasterthanlime]

Taking this out of draft since it's ready for being merged imho!

[fasterthanlime]

I caught another template issue (a benign one) while working on #1509 — which mostly tells me the homebrew stuff isn't all covered by unit (or integration) tests

[mistydemeo]

Looking good, but a few comments - one error, and a few other suggestions and questions.

[fasterthanlime]

probably due to the minijinja update? idk

[mistydemeo]

What version of cargo-insta do you have? This was added when Ellen updated a test, which makes me think they might have a newer version than you or I do.

[mistydemeo]

OK yeah, this field landed in cargo-insta 1.41 mitsuhiko/insta@0b81773

Prior to that insta only had a single snapshot format so there was no need to specify.

[fasterthanlime]

I’ll upgrade locally!

[fasterthanlime]

@mistydemeo I addressed whitespace issues — in fact, I made sure the template produces exactly the same input as before, just using those nice macros and the new "template input" structs.

I've also added a comment about the jinjaness of the macro (and a link to the surprising-to-find docs), and fixed the endif/end mishap.

[mistydemeo]

Looking good, just a few comments now!

[fasterthanlime]

The mac tests are failing because it's trying to install a linuxbrew-only package..