2023-11-13 Nix team meeting minutes #103

Development Nix
1

Attendees: @thufschmitt @edolstra @tomberek @fricklerhandwerk @infinisil (@ericson2314 later)
Notes by: @fricklerhandwerk

Agenda

Fundraiser goal refinement

Discussion

Progress indicator improvements by edolstra · Pull Request #4296 · NixOS/nix · GitHub

  • idea approved as an additional progress bar
    • it doesn’t need to be guarded by experimental feature since there is no inherent stability guarantee

Move unit tests to separate directories, and document by Ericson2314 · Pull Request #8886 · NixOS/nix · GitHub

builtins.fetchTree

  • @fricklerhandwerk: discussed with @roberth last time about a more structured interface to check for input attributes and specify documentation, something along the lines of how configuration works, just more light-weight
    • interface could go something like this to be easier to document and reason about:
      builtins.fetch.git { url = "..."; rev = "..."; ... };
      then output attributes can be exactly the same as the input
      • @edolstra: this is not necessarily a UI improvement and bikesheds on an interface that existed for 3 years
      • @thufschmitt: the problem seems like it’s contesting the original idea of having one unified function that, whatever you give it, will return a file system tree
      • @edolstra: the lock file currently exposes the type attribute, and that would entail breaking the lock file format
        • need to have good arguments for such changes
        • @fricklerhandwerk: changing the lock file format forward is much easier than with the language
        • @thufschmitt: can have both by wrapping that into a generic fetchTree, that would allow documenting the defining functions independently
          • @edolstra: don’t see any advantage to this
      • @edolstra: one aspect to consider is that if the fetcher type is unknown (e.g. supplied by a plug-in), and is supplied a narHash, one can still substitute the contents from the store
      • @thufschmitt: a unified function has the advantage that you can give it any input and not have to dispatch manually over the type
        • tagged unions are routinely dealt with in JSON, so that shouldn’t be a problem per se
        • @infinisil: semantically these are equivalent and can be mapped between
          • the tagged union makes most sense if all of the types return the same thing, otherwise not
  • @Ericson2314: @roberth has something cooking to implement that [more declarative attribute checking], and it may pave the way to reduce the number of globals required for general configuration as well as other scaling opportunities, but it may take a while
    • until then could have map to define the arguments and documentation, can get to it in the next week or two
  • no decision until we have code to look at
  • Git smudging?
1 Like