2023-06-26 Nix team meeting minutes #66

Development Nix
1

Attendees: @roberth @ericson2314 @edolstra @thufschmitt @fricklerhandwerk

Agenda

RFC 110

Gave feedback as requested by @r-burns.

RFC 137

  • @thufschmitt: not sure about the minor version numbers
    • @fricklerhandwerk: the purpose is to signal to expression authors when bumping a version will definitely not require changes to existing expressions
  • @roberth: This appears to reduce the usefulness of Nixpkgs.lib as a “libc” that takes advantage of the latest “kernel”
    • if this is implemented, lib won’t be able to access the latest stuff any more
      • it will also have to be a pretty low version to be compatible with a variety of Nix evaluators
    • @fricklerhandwerk: yes, the proposal reveals the underlying question whether a compatibility window is worth more than determinism
      • @roberth: could have both, if lib would be able to deal with a version range of the language
  • @ericson2314: the general direction is good
    • only question is what to do with mixing files with different versions, may need discussion
    • may want to reserve the right to say that importing incompatible versions may fail
    • @thufschmitt: don’t even see a near-term future where we’d make such a breaking change that cross-version interfaces wouldn’t work out
  • @thufschmitt: main question is how costly this will be in terms of maintenance
    • would have to keep old evaluators around for potentially many versions
    • but architecture is currently not made for that
    • @ericson2314: for most changes we envision there probably isn’t the need to change the architecture of the evaluator
      • once we need multiple interpreters we may get into trouble mixing versions, the problems seem related
    • @thufschmitt: yes, and it’s probably not a blocker for this RFC
  • (some discussion of explicit annotation and relation to file system location)
  • @edolstra: we could prediate this proposal on flakes, because then we’d have a unit to be versioned
    • otherwise every file in Nixpkgs will need a version annotation
      • @fricklerhandwerk: it’s a one-liner to add it treewide
      • @edolstra: lots of spam, wouldn’t want this in tens of thousands of files
    • @roberth: this proposal can be independent of flakes, and flakes would add the option to declare the version for the entire project
    • @ericson2314: how would we then associate a Nix file with a flake?
      • you can still import expression from arbitrary places
    • @fricklerhandwerk: would have the advantage of a project concept, but would block this proposal (which seems less controversial) on flakes (more controversial)
      • @ericson2314: should have a solution that flakes can build on top of
  • @roberth: alternative proposal: .nix-version file to determine the version to use for this file system tree
    • when parsing, go up the directory tree until one is found, otherwise fall back to some default
    • downside: moving Nix files may lose the version annotation
    • @edolstra: adds more clutter to Nix projects
    • @thufschmitt: closer to what exists otherwise
      • could eventually let flake.nix take that role
      • @ericson2314: similar to Cabal files where you can define default extensions
  • @ericson2314: this will raise the bar for making changes, forcing us to be more deliberate about what is supposed to be in the language
    • @thufschmitt: agreed, this is probably good for third-party implementations
  • @ericson2314: do we consider things like extensions
  • @thufschmitt: how would we treat bugs?
    • @fricklerhandwerk: reasonably, hopefully. it opens the question of separating specifciation from implementation. currently we have to appeal to intent

Reviews

Further search path cleanups by Ericson2314 · Pull Request #8579 · NixOS/nix · GitHub

  • @ericson2314: is something like this asdf/qwer/zxcv=foo/bar/baz being a valid search path intended?

reword description of how realisation works by fricklerhandwerk · Pull Request #7592 · NixOS/nix · GitHub