2023-01-13 Nix team meeting minutes #23

Development Nix
1

Attendees: @thufschmitt @roberth @fricklerhandwerk @edolstra @tomberek @Ericson2314

Agenda

  • Triage (30 min)
  • Discussion (30 min)

Triage (and some discussion)

Flakes design discussion

Agenda for next time

  • @roberth: explore the problem and design space of what flakes try to achieve
  • @fricklerhandwerk: we’re currently duplicating work for writing down what we do with the PRs. should use labels instead, because GitHub preserves history of changes
    • @roberth: board columns can be based on labels, too
    • then we can use a script to produce a log for the meeting notes
2 Likes
2

Regarding the smudge filter and fetchGit, I’m unclear on how far these changes would extend if implemented, and fear that use of git-crypt with flakes might be effectively broken by them.

I want to be able to keep using git-crypt with flakes, though I agree that the current status quo of silently behaving non-deterministically isn’t acceptable. Unlocking with git-crypt should need to be explicitly specified in the flake url, since the “unlocked” version is a distinct flake. It would also be nice if this was supported for more flake url schemes, such as github:. However, this explicit specification of git-crypt needs to be implemented simultaneously with the removal of the current behavior so as not to leave those using git-crypt out of luck.

Git-crypt has a place in the flakes ecosystem for “private data” rather than “secrets” as such. I use it for personal aspects of my config such as which rss feeds I subscribe to. It’s not a secret, but I don’t particularly care to share it with the world on github, either. It’s also not bad for an additional layer of protection on somewhat poorly protected secrets such as password hashes.

3

Regarding smudge filters, it was mentioned in the meeting that the git CLI does too many things at once for us. We might want to move towards libgit2 for git fetching, which lets us work closely with the “nice and predictable” tree/blob representation directly. This approach would also work well with lazy trees.

It would then make sense to implement popular and reproducible smudge filters one by one, each behind a treeref flag.

We may have to either break the lock file or the fetchTree semantics, but we’re still looking into this and we’ll try to minimize the impact if at all possible.

Also here’s another similar git fetcher impurity Unstable NAR hash for `git` inputs using export-subst · Issue #7596 · NixOS/nix · GitHub

4

Sounds like not a lot is decided at all, but if things go the way they’re leaning, git-crypt will certainly make the list of popular smudge filters, but there might be a, hopefully short, period in which support for it lapses. I suppose at worst I’ll have to pin to an old version of nix for a while.

When the time comes, I hope a bit of thought is given to the ergonomics of using smudge-filtered flakes from the CLI after the change. Once you decide you’re going to use them, hopefully the trappings of doing so can be kept out of your way as much as possible.

Thanks for clarifying, and moving closer to the base git data representation seems like the right move to me, too. It’s just a matter of the hiccups along the way.