This is one of the better-scoped proposals I've had - thank you. You did the thing most infra suggestions skip: stated the non-goals up front, kept the native path primary, and were honest that this is a reproducible reference environment rather than a fix for the underlying compatibility problems. And your premise checks out - I went back through the issues you cited (#1, #60, #147, #186, #157, #226, #242) and setup/dependency friction really is a recurring theme across a lot of different contributors, not a one-off.

Where I land, though, is community-adaptation-first - and I want to explain the reasoning rather than just point you at a fork.

The friction in those issues comes almost entirely from MiKTeX, apt, and general-setup users - the exact population that, as you note, mostly won't have Nix. So a flake helps the Nix-using slice and gives us a clean reference env, but it doesn't relieve the pain for the people actually filing those reports. Set against that, a flake.nix/flake.lock in the upstream tree is an ongoing maintenance surface: the lock has to be refreshed as nixpkgs and the pinned tools move, or the "reproducible" promise quietly rots. For a narrow-audience convenience I'd want that to prove out before it lives upstream.

So here's a genuine path, not a brush-off: build it in your fork (or a branch), and if you can show two things - that nix flake check mirrors what ci.yml already runs by calling the same scripts rather than a parallel copy that can drift, and that the lock stays low-touch over a few dependency bumps - I'm very open to revisiting upstreaming it, likely as a fully optional, non-blocking path. I'll link it from the community adaptations thread (#78) either way so Nix users can find it.

One thing worth noting: you're right that texlive/texlive:latest is unpinned, and there's a real question about how representative the CI TeX environment is of what users actually get through apt - that's live right now in #242. I'm going to weigh the CI-image side of that as part of resolving #242 rather than in isolation, since pinning and "make CI catch apt-version bugs" can pull in different directions. Good catch either way. Thanks again for the care here.

I made the fork and PR here, as to not spam your repo:
https://github.com/jakob1379/ai-job-search/pull/1

I tried to add caching, but since this repo only depends on already existing tools, nix themselves has it cached so I removed the ci caching again as it did not yield any positive results (it took longer to revive the cache than pull cached deps again...). I kept the timing results for documentation purposes.

The main gain by having this is a super simple dev-setup nix develop and then you have all you need deps needed. Same goes for deps in CI.