Spam due to `lib.warn` usages in `aliases.nix` when running `nix search` for the first time.

[doronbehar]

Describe the bug

I'm using nixos-unstable, and for the sake of demonstration, I took a nix search that for sure isn't cached for me:

$ nix search github:nixos/nixpkgs/release-24.05 cudatoolkit
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
* legacyPackages.x86_64-linux.cudaPackages.cudatoolkit (12.2)
  A wrapper substituting the deprecated runfile-based CUDA installation

* legacyPackages.x86_64-linux.cudaPackages.cudatoolkit-legacy-runfile (12.2.2)
  The deprecated runfile-based CUDAToolkit installation (a compiler for NVIDIA GPUs, math libraries, and tools)

* legacyPackages.x86_64-linux.cudaPackages.markForCudatoolkitRootHook

* legacyPackages.x86_64-linux.cudaPackages.saxpy (2023-07-11)
  A simple (Single-precision AX Plus Y) FindCUDAToolkit.cmake example for testing cross-compilation
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead

* legacyPackages.x86_64-linux.cudaPackages_10.cudatoolkit (10.2.89)
  The deprecated runfile-based CUDAToolkit installation (a compiler for NVIDIA GPUs, math libraries, and tools)

* legacyPackages.x86_64-linux.cudaPackages_10.cudatoolkit-legacy-runfile (10.2.89)
  The deprecated runfile-based CUDAToolkit installation (a compiler for NVIDIA GPUs, math libraries, and tools)

* legacyPackages.x86_64-linux.cudaPackages_10.markForCudatoolkitRootHook

* legacyPackages.x86_64-linux.cudaPackages_10.saxpy (2023-07-11)
  A simple (Single-precision AX Plus Y) FindCUDAToolkit.cmake example for testing cross-compilation
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead

* legacyPackages.x86_64-linux.cudaPackages_11.cudatoolkit (11.8)
  A wrapper substituting the deprecated runfile-based CUDA installation

* legacyPackages.x86_64-linux.cudaPackages_11.cudatoolkit-legacy-runfile (11.8.0)
  The deprecated runfile-based CUDAToolkit installation (a compiler for NVIDIA GPUs, math libraries, and tools)

* legacyPackages.x86_64-linux.cudaPackages_11.markForCudatoolkitRootHook

* legacyPackages.x86_64-linux.cudaPackages_11.saxpy (2023-07-11)
  A simple (Single-precision AX Plus Y) FindCUDAToolkit.cmake example for testing cross-compilation

* legacyPackages.x86_64-linux.cudatoolkit (12.2)
  A wrapper substituting the deprecated runfile-based CUDA installation

* legacyPackages.x86_64-linux.cudatoolkit_11 (11.8)
  A wrapper substituting the deprecated runfile-based CUDA installation
trace: warning: eww now can build for X11 and wayland simultaneously, so `eww-wayland` is deprecated, use the normal `eww` package instead.
trace: warning: lxd has been renamed to lxd-lts
trace: warning: lxd-unwrapped has been renamed to lxd-unwrapped-lts
trace: warning: nixfmt was renamed to nixfmt-classic. The nixfmt attribute may be used for the new RFC 166-style formatter in the future, which is currently available as nixfmt-rfc-style
trace: warning: nvtop has been renamed to nvtopPackages.full
trace: warning: nvtop-amd has been renamed to nvtopPackages.amd
trace: warning: nvtop-intel has been renamed to nvtopPackages.intel
trace: warning: nvtop-msm has been renamed to nvtopPackages.msm
trace: warning: nvtop-nvidia has been renamed to nvtopPackages.nvidia
trace: warning: writeReferencesToFile is deprecated in favour of writeClosure

This is too noisy.

Steps To Reproduce

1. nix search a nixpkgs revision that is not cached.
2. See too many warnings that are not even related to the search word you gave nix.

Expected behavior

No warnings

nix-env --version output

nix-env (Nix) 2.18.2

Additional context

This has bugged me for a while, but now that https://discourse.nixos.org/t/how-to-introduce-a-breaking-version-bump/46746/9 is being discussed, I thought this should be reported.

Priorities

Add :+1: to issues you find important.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-introduce-a-breaking-version-bump/46746/10

[jtojnar]

Nixpkgs issue: https://github.com/NixOS/nixpkgs/issues/306276

[roberth]

• Public attributes should be able to produce warnings, so they can implement a deprecation cycle.
• These warnings are not relevant to the search.

Then it follows that nix search should ignore builtins.trace and builtins.warn. What follows from that is a risk that some kind of important warning is not shown when it affects search. I doubt how frequently that would happen, and presumably the expressions are maintained in such a way that warnings are seen by their developers.

[doronbehar]

What follows from that is a risk that some kind of important warning is not shown when it affects search. I doubt how frequently that would happen, and presumably the expressions are maintained in such a way that warnings are seen by their developers.

Yea I too can't sketch a situation where an end user would want to know about these warnings - nix search is usually used by external users of flakes such when you want to discover what packages are distributed by a flake. The main dilemma IMO is to decide whether attributes that raise warnings should appear in the nix search output - right now I see they do appear, and since they do appear, perhaps it would make sense to only show the warnings when you build the attributes? I'm not sure.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/after-updatting-from-23-05-to-24-05-i-get-graphical-bugs-and-nix-env-u-deprecated-warnings/47862/3

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/errors-out-of-the-box/48885/2

[philiptaron]

Does the new builtins.warn help with this?

https://nix.dev/manual/nix/2.23/release-notes/rl-2.23

[roberth]

Potentially, though I think warn and trace are equally irrelevant to nix search, and should both be silenced. At least builtins.warn is perhaps worth adding a single-line notice about, whereas trace could be something for debugging and whatnot. The message could be something like:

Evaluating <...> produced warnings. Pass --show-warnings if needed.

[philiptaron]

That's a worthwhile Nix quality of life feature. I'm assuming there's no way for evaluation or lib.warn to understand that it's being called in a nix search context?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-08-21-nix-team-meeting-minutes-171/50950/1