2023-11-20 Nix team meeting minutes #105

Development Nix
1

2023-11-20 Nix team meeting minutes #105

Attendees: @edolstra, @ericson2314, @roberth, @tomberek, @thufschmitt

Introduce libgit2 by edolstra · Pull Request #9240 · NixOS/nix · GitHub

  • Was waiting on the release, but the release has been made, so free to merge now
  • @ericson2314 will fix the merge conflict
  • Merged!

fetchGit/fetchTree: add support for shallow cloning by DavHau · Pull Request #9376 · NixOS/nix · GitHub

  • The current semantics of shallow = true are non-intuitive

    • Currently just means “the remote is shallow”, while we want “fetch things in a shallow way”
      • The old behavior could be useful for local shallow repositories, but rather edge-casy
    • Shallow fetching is limited by the revCount attribute. Should we get rid of it by default?
      • Actually we can do treeless fetching, which would still be faster than eagerly fetching and give us the revCount.
    • What about a shallow remote?
      • @roberth: Can look at that remote’s remotes (since it is likely to be a local clone)

  • “blobless” and “treeless” are newer terms than shallow

Possibilities for fetching:

  • treeless. Woudln’t change the interface. Gain benefits unknown (very likely slower than shallow for a fresh clone and faster with good caching). Not sure whether it’s supported by libgit
    • roberth: libgit support is not a prerequisite. Shelling out is ok - just not preferable when there’s a choice
  • shallow. Doesn’t allow revCount (so probably should be optional). Probably fast for a fresh clone, but no real caching. Supported by libgit

Tentative plan (two alternatives) written in this issue: Shallowness of git fetching · Issue #9402 · NixOS/nix · GitHub

fetchTree/fetchGit: add test for .gitattributes by DavHau · Pull Request #9391 · NixOS/nix · GitHub

Do we want this behavior in the long run? And can we have it with libgit2

  • Breaking that breaks the hashes of fetchGit (when the directive is used)
  • libgit has a way to read the gitattributes file, so we can reimplement it, but with a bit of work
  • Alternatively, we can break it, and be explicit (warn) about it
  • No decision on the PR, will have to investiate the different options.

Allow `builtins.storePath` in pure mode · Issue #5868 · NixOS/nix · GitHub

  • Should we consider builtins.storePath pure?
    • Technically as pure as any fetcher
    • But maybe not because it doesn’t specify where to fetch from (just fetches from any ambiant binary cache defined in the configuration)
    • This can be emulated (even in pure mode) by hacking around builtins.appendContext. So keeping it impure is a bit of a lie
    • The main issue with builtins.storePath is that a expression that uses it can never work on its own; it always needs external substituter configuration (i.e. the user needs to read some README to figure out how to get the flake to work).
      • Possibly, we could allow a stricter storePath that requires that the path is present in the store. That would solve a number of use-cases while being much less controversial
  • No agreement, postponed
3 Likes