Optional Nix development environment for reproducible setup

[jakob1379]

Context

I have followed this repository for some time, and dependency/setup
friction seems to be a recurring theme:

• TeX and moderncv installation/version differences (LaTeX Error: File `moderncv.cls' not found. #1, docs: add minimal TeX setup instructions #60, added missing template dependency to SETUP.md #147,
  docs: add Basic MiKTeX setup instructions for Windows #186, and currently cv/main_example.tex fails to compile on apt-packaged moderncv (Debian/Ubuntu TeX Live) #242)
• Repeated per-CLI Bun installation and dependency drift (docs(readme): make install loops failure-isolated per iteration #157 and fix(cli): pin @types/bun and @bunli/* to stop CI type-drift #226)
• CI using texlive/texlive:latest, which can differ significantly from
  packages users receive through apt (ci: add GitHub Actions workflow — LaTeX smoke compiles, skill lint, CLI typechecks, placeholder integrity #59 and cv/main_example.tex fails to compile on apt-packaged moderncv (Debian/Ubuntu TeX Live) #242)
  The existing native setup instructions should remain the primary path,
  since most users will not already use Nix.

Proposal

Would you be open to an optional flake.nix and flake.lock for users
and contributors who already use Nix?
A deliberately narrow first version could:

• provide Bun, Python, the required TeX packages, and Poppler through
  nix develop
• pin those system dependencies through flake.lock
• expose deterministic lint, Python, security, and LaTeX smoke checks
  through nix flake check
• leave Claude Code installation/authentication and Bun package
  installation unchanged initially
• leave the existing README/SETUP instructions and stock LaTeX workflow
  untouched
  This would provide a reproducible reference environment, not replace
  direct fixes for platform compatibility problems such as cv/main_example.tex fails to compile on apt-packaged moderncv (Debian/Ubuntu TeX Live) #242.

Non-goals

I would not initially attempt to generate apt/.deb, Flatpak, or Docker
releases. The repository is template rather
than a single packaged application, and those distribution targets have
different runtime and user-data requirements.
An OCI image could be considered later if a concrete use case emerges.

I use Nix and would be happy to help prototype and validate this
direction. Would this be useful upstream, or would you prefer it to live
as a community adaptation?

[MadsLorentzen]

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.

[jakob1379]

the good thing is that nix is in dependabot, so updating is not a manual process, I'll gladly make a fork and PR to show how it would work if dependabot way is something you'd like otherwise I have to make a manual ci to update it.

[MadsLorentzen]

Confirmed - Dependabot added Nix ecosystem support in April 2026 (version updates for flake inputs; public repos only, which fits here). That's the route I'd want if this proves out: no hand-rolled update CI, just a dependabot.yml entry, and the "lock quietly rots" concern I raised mostly dissolves.

So yes - go the Dependabot way in your fork demo. The two proof conditions from my earlier reply stand as the bar for revisiting upstream: nix flake check calling the same scripts ci.yml runs (not a parallel copy that can drift), and the lock staying low-touch across a few Dependabot bumps. Ping me here when it's up and I'll link it from #78 either way.

[jakob1379]

I made the fork and PR here, as to not spam your repo:
jakob1379#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.

[jakob1379]

also it showed that a much smaller texlive distribution is enough to pass CI which reduces download size to ~600MB