2024-08-21 Nix team meeting minutes #171

Development Nix
1

Attendees: @edolstra (first half) @robert @tomberek (second half)

Spam due to `lib.warn` usages in `aliases.nix` when running `nix search` for the first time. · Issue #10882 · NixOS/nix · GitHub

Brainstorming

  • Should these warnings be emitted at all?

  • Maybe Nixpkgs could solve this, e.g. legacyPackages could be silent?

    • But then how do we make renames and deprecations work?

  • What if the warning is actually about a serious problem that affects the search?

    • Unlikely; they tend to be just renames and deprecations

  • Warnings aren’t always actionable. E.g. when a dependency needs to change its behavior, instead of the user’s expression.

  • nix-env -qa behaves the same, and so would nix flake show, nix flake check

  • Nixpkgs 23.11 and older weren’t this noisy

  • Maybe Nixpkgs could print the warning only when a package is instantiated (e.g. only warn in outputs, outPath and the output attributes)
    This way the attribute itself and type are silent

  • Deprecation primop, or even a language feature for attributes, meta.deprecated

Conclusion: this seems to be have been caused by Nixpkgs. Could it be solved there? Designing a good solution on the Nix side is non-trivial.

Suggestion: trace: warning while doing nix-env -u · Issue #306276 · NixOS/nixpkgs · GitHub

Add optional `date` argument to `builtins.fetchGit` by Gabriella439 · Pull Request #7362 · NixOS/nix · GitHub

What would be the right primitives for this?

  • Idea: perhaps fetchGit/fetchTree could support this in a pure way.

    inputs.a = { type = "git"; ref = "main"; }  # lock: rev = ...
inputs.a-base = { type = "git"; rev = inputs.a.rev; roundDown = "1 day"; }

    In this example, the roundDown attribute would implement the desired behavior and could be implemented

Lazy `fetchTree` `outPath` path values by roberth · Pull Request #10252 · NixOS/nix · GitHub

@tomberek will try to rebase and look into it.

4 Likes
2

It would be better if there are "derivation placeholder"s, providing renamed or removed message but showing up in a nice way in nix search and search.nixos.org. Not sure if this is worth having nix builtin for, or we can just agree on a certain set structure to define it.

3

Nixpkgs could probably define it to be a “fake” package attrset with a meta.description that describes what to do and a set of outputs that either warns or throws.

1 Like
4

On “packages”: Discussions like this one remind me of how everything is still awfully conditioned to think in terms of files, and, by extension derivations.

Apart from maybe performance considerations and backwards compatibility or migration costs, nothing in principle prevents us from thinking of a package as a language-level data structure with some fields being derivations — instead of vice versa as it currently stands. We’re free to design that data structure and the interactions with it as needed for building a software distribution or an operating system. There’s no need to constrain oneself by whatever incidental or conventional file-system-level peculiarities shipped with the software we’re packaging.

Nothing forces us to think that a package without a derivation is in any sense “fake”.

6

@fricklerhandwerk That is exactly right. Those scare quotes were very load bearing.

1 Like