2023-03-06 Nix team meeting minutes #38

Development Nix
1

Attendees: @Ericson2314 @fricklerhandwerk @edolstra @thufschmitt (later: @tomberek)

Notes: @fricklerhandwerk @Ericson2314

Agenda

Notes

  • @fricklerhandwerk started drafting a report on the past months of work
    • @edolstra: stopped gathering release notes from the git log. Similarly wanted to avoid any other rote O(n) task.
    • @fricklerhandwerk: this is supposed to not be rote, and rather a moment of reflection
      • Preparing a draft report is rote and I’ll take that work, helped by ChatGPT for summarising reams of text
      • reviewing the draft together and reflecting on what and how we did is the purpose of the mental exercise

Discussion

CLI stabilisation announcement draft

  • @Ericson2314: should work out the division of labor between the team’s announcement and RFC 136
  • @edolstra: not in favor of stabilising incrementally, but only reviewing incrementally
    • think we’re creating a lot of work for us
    • should describe this as incremental review, not stabilisation
    • also don’t want to mark individual commands as experimental, that’s a lot of overhead
  • @Ericson2314: if we do CLI before flakes we’ll need the partially experimental infrastructure anyway
    • @edolstra: no, flakes already have a separate experimental feature flag
    • @Ericson2314: flakes are a global feature, but --help lists all the flakes stuff anyway
      • @edolstra: help should not require that, the command will tell you when you try to use it
    • @fricklerhandwerk: agree with @Ericson2314, we should be much more clear in the communication because so far the ambiguous messaging puts a lot of strain on beginners
      • this is surely worth the effort, and @Ericson2314 has done most of the work already
      • (general but not unanimous agreement)
      • @edolstra: don’t think documentation should have lots of conditionals, this is not a good use of our time
    • @edolstra: have no interest in a CLI without flakes, as it has no compelling value over the old CLI. If that’s what we go for then we would have spent several years without progress
      • @tomberek: are they incompatible?
        • one problem is that we’re accumulating features faster than we can take care of them
        • there may be multiple ways to chop up the large problems to make them more manageable
          • we’re currently trying to do this by layer, but we may do this by feature
          • really this is an issue of process and communication, for setting the right expectations and induce the right conceptions about what’s going on
          • implementation may not be as intetwined as people think
          • @edolstra: it is intertwined, the new CLI is fundamentally built around flakes
    • @fricklerhandwerk: What about comands like nix shell and nix develop, that may be hard to stabilize? Should we block on them, stabilize them with the others anyways, or leave them for later?
      • @edolstra: We could stabilize them later. Still concerned about incremental formal stabilizing in general.
    • @fricklerhandwerk also wants to push more against the notion that incremental stabilization is costly
      • There is a big desire for clearer communication amongst in community.
      • This would be a clear win on that front
      • Thinks it is less effort than Eelco does, especially as John already did the work on the infrastructure.
  • @edolstra: OK maybe marking commands isn’t so bad
    • A little confusing when only a few random commands are stable
    • Less opposed to automatic infrastructure like marking commands unstable than more manual stuff like “ifdef-ing” the prose documentation
  • @Ericson2314 how about this:
    • incremental review is definitely good
    • incremental formatlization is good
    • should go more for the automatic stuff, e.g. marking individual commands and options experimental, and do less manual work
    • we could combine incremental review and incremental stabilisation by that, which would help with landing stable features earlier
  • @edolstra: How come the document mention review then stabilization, doesn’t that mean we don’t get the incremental communication benefits?
    • @ericson2314: Yes that was a problem with it, stemming from the fact that we couldn’t agree on adding more automatic marking. But now that we can, we can change this to fix this.
  • @tomberek and @fricklerhandwerk will fix up the draft according to feedback and reinforced agreements
    • we gather as consensus:
      • combine what’s currently step 2 and 4, leveraging fine-grained experimental flags per command and option in order to land things as quickly as possible
      • make what’s currently step 3 incremental
      • no promises about timelines
      • finalise and publish after RFC 136 is accepted

XDG and profile paths post-mortem

Team membership

12 Likes
2

I fail to interpret this.

There is a new CLI structure. There are specific improvements, like new nix copy scope, nix build progress display, and many more. There are flakes.

Then there are improvements in how the builds are run.

From the notes here, I fail to extract any logical connection why any single thing out of these four is supposed to be an improvement in combination with others, but not an improvement if just done well on its own.

Could someone please clarify?

3 Likes
3

I think what he’s getting at here is how some of the nice features of the new CLI, i.e., nix run, rely on flakes (and how flakes was created to support those features).

But I agree with you that there is also considerable value in more or less orthogonal parts of the new CLI, and so I would appreciate some clarification, too.

4

Actually the stuff claimed to be «tied to flakes» is not really semantically tied to flakes fo any good reasons. nix run =nixpkgs#blender looking up nixpkgs in NIX_PATH instead would be just as useful. I mean, I have had a wrapper script that does effectively this for longer than flakes have been discussed in public.

Even worse, I remember there was some discussion that something useful in new CLI was first compatible with both flakes and non-flake repositories, and then downgraded to flakes-only.

4 Likes
5

This is my understanding as well. Before 2.4, the new CLI could build non flakes projects equally. My concern with stabilizing the new nix build CLI without replacing at least the functionality of nix-build -A is that it would constitute an implicit deprecation of non-flakes projects (by the absence of clean ways to build them), which I don’t imagine is a goal.

In order to use the new CLI to build a non flake project, I believe you need to pass nix build --impure --print-build-log --expr '(import ./default.nix).myAttr' although I may be missing some flags there.

3 Likes
6

Great to have detailed notes. Thank you!

YES

1 Like
7

@jade I guess what you want to achieve can still be done via nix build -f . hello. What’s not possible anymore is to use things from NIX_PATH as installable (i.e. nixpkgs.hello pointing to hello from your nixpkgs defined in your NIX_PATH).

This doesn’t work for all commands though, e.g. not for nix why-depends:

❯ ~ → nix why-depends /nix/var/nix/profiles/system -f ~/Projects/nixpkgs-backports cargo
error: attribute '/nix/var/nix/profiles/system' in selection path '/nix/var/nix/profiles/system' not found
❯ ~ → nix why-depends /nix/var/nix/profiles/system nixpkgs#cargo                        
/nix/store/c9mw7xggc6p2cza82i5nxv0400vzrhq8-nixos-system-carsten-22.11.20230304.211b3c0
└───/nix/store/y87ayqymyrl6g9lhazfxd13i5lap2jcb-etc
    └───/nix/store/b3gq08fyfdvblmxifclw73kc19jgq9ln-user-environment
        └───/nix/store/wkbxwz7vxffjzp06jmn07qrky56fbd6n-home-manager-path
            └───/nix/store/6m44jfs2iflcpihjf5h3mz5a431j0362-evcxr-0.14.1
                └───/nix/store/zx8zx3alfhwcs6qppv8rz3zga5ckm276-cargo-1.64.0

While you could determine the store-path of cargo via another command and substitute it into the nix why-depends call here, I guess it’s fair to say that this became rather flake-centric.

2 Likes
8

Eh? What about all the features that only exist in the new CLI? (nix log, nix eval --raw, nix store copy-logs, nix show-derivation, nix path-info, etc.) As I understand it, adding features to the old CLI hasn’t been allowed, so we’ve ended up with lots of value in the new one independent of flakes.

9 Likes