aliases: warnOnInstantiate all aliases if `config.warnAliases=true` by pbsds · Pull Request #414658 · NixOS/nixpkgs

pbsds · 2025-06-07T06:02:48Z

The problem with ever dropping aliases from aliases.nix is that downstream users have no idea that certain attributes they rely on have been an alias for years. With warnings however we can expect users to be able to migrate, which in turn enables dropping aliases a lot quicker. With this merged i believe #414656 is very much possible

Tested with nix-env and on my nixos config.

I wanted to make config.warnAliases default to false for normal nixpkgs but true for nixos, but i could not figure out how to set that default without it then ignoring whatever the user configures in their nixos config.

I took extra care to make sure the implementation is performant and that there are no huge footguns in aliases.nix. It is possible for .__aliasWarningAttrName to leak, which is the case for vamp.vampSDK, but i believe this is not a real issue.

Showcase:

The jami-client alias is defined as:

jami-client = jami; # Added 2023-02-10

If you try to use it you wouldn't know it is an alias unless you use the nuclear option allowAliases=false:

$ nix-build . -A jami-client
/nix/store/0dz9vmg7r9wnh30kx95m6vc4s240wgb2-jami-20250523.0
$ nix-build . -A jami-client --arg config '{ allowAliases=false; }'
error: attribute 'jami-client' in selection path 'jami-client' not found

but with this PR you will instead see

$ nix-build . -A jami-client
trace: evaluation warning: 'jami-client' has been renamed to/replaced by 'jami'
/nix/store/0dz9vmg7r9wnh30kx95m6vc4s240wgb2-jami-20250523.0
$ nix-build . -A jami-client --arg config '{ warnAliases=false; }'
/nix/store/0dz9vmg7r9wnh30kx95m6vc4s240wgb2-jami-20250523.0
$ nix-build . -A jami-client --arg config '{ allowAliases=false; }'
error: attribute 'jami-client' in selection path 'jami-client' not found

Here is the stderr output of nix-env --extra-experimental-features no-url-literals --option system x86_64-linux -f ./. -qaP --json --meta:

https://gist.github.com/pbsds/bd6b4211086db4d6707cba98e0fcf5c7

(all of these examples had .outputName and .system excluded from warnOnInstantiate)

Things done

Add a 👍 reaction to pull requests you find important.

This makes use of 'self' explicit in the let block, and communicates that 'super' should not generally be used in this file.

nixos-discourse · 2025-06-11T18:45:50Z

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

https://discourse.nixos.org/t/prs-ready-for-review/3032/5564

hsjobeki

Neat change.
I see two open questions:

lib of pkgs should be strictly equal to just importing lib otherwise that could open the box of pandora. cc @roberth @infinisil
Should there be a more granular decision for warnAliases ?

hsjobeki · 2025-06-20T06:03:07Z

pkgs/top-level/aliases.nix

+    else
+      name: alias: alias;
+
+  lib = lib'.extend (


use of extend was discouraged. cc @roberth.
possibly extend lib without calling extend,
I am a bit worried about this because after this PR:
pkgs.lib != lib

A similar change was made in flake.nix and was highly regreted. We have to maintain that parallelism now and people are confused because about why lib is having different functions sometimes - depending how you import it.

Maybe bind __aliasWarningAttrName = { warnAliases = true; } ? That would also allow perPackage decisions which by default inherit true from the config of pkgs ?
(Just playing with ideas here)

How about renaming lib to _lib in the file with a comment about how only using the "whitelisted" functions from a inherit (_lib) ...; in the let binding is allowed? Then we're free to make custom versions of some of the lib functions.

Maybe bind __aliasWarningAttrName = { warnAliases = true; } ? That would also allow perPackage decisions which by default inherit true from the config of pkgs ?
(Just playing with ideas here)

I don't quite understand what you mean by this nor what it achieves.

Pandapip1 · 2025-07-21T00:58:09Z

I wanted to make config.warnAliases default to false for normal nixpkgs but true for nixos, but i could not figure out how to set that default without it then ignoring whatever the user configures in their nixos config.

Wouldn't adding simple nixos module

{
  lib,
  ...
}:

{
  config.nixpkgs.config.warnAliases = lib.mkOptionDefault true;
}

work?

mdaniels5757 · 2025-07-21T00:59:07Z

Some aliases (e.g. clangXXStdenv) are intended to be kept indefinitely as alternative names, so I imagine a warning would be undesirable for them. Would this be a problem for those aliases?

~~Also, some aliases are not for derivations, but rather for functions. (e.g. runCommandNoCC, system). So lib.warnOnInstantiate won't work for them.~~ Never mind, I missed line 219.

roberth · 2025-07-21T06:32:37Z

This is a very welcome change in behavior, but I think it needs to be a bit bolder, so that it can avoid complicated workarounds.
What if an alias definition looked like this?

let inherit (pkgs) handleAlias;
#...

foo = handleAlias { old = "foo"; new = "bar"; value = bar; release = 2511; };

Then handleAlias is defined in a scope where it can access the required context like config to make a decision, and the call contains all the info in an explicit way, without having to smuggle or override anything.

Speaking of smuggling ;), I've snuck a release attr in there that you could use to control when warnings are activated, perhaps using lib.oldestSupportedReleaseIsAtLeast.

wolfgangwalther · 2025-09-14T16:51:07Z

What if an alias definition looked like this?
[...]

Another alias related draft PR can be found at #442066, where I intend to introduce "structured aliases" to solve some of these same problems (eventually).

pbsds · 2025-09-14T19:58:58Z

I'm much more interested in mass-migrating the current aliases to that system once it is ready

aliases: move 'with self;' below let-in block, prefix 'super' with '_'

66fe92b

This makes use of 'self' explicit in the let block, and communicates that 'super' should not generally be used in this file.

github-actions bot added the 8.has: documentation This PR adds or changes documentation label Jun 7, 2025

Aleksanaa requested a review from RossComputerGuy June 7, 2025 06:06

github-actions bot added 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Jun 7, 2025

pbsds mentioned this pull request Jun 7, 2025

aliases: make aliases supported for 2 years/4 releases #414656

Draft

13 tasks

aliases: warnOnInstantiate all aliases if config.warnAliases=true

3b5db57

pbsds force-pushed the feat-warn-aliases-1749253960 branch from 8689eeb to 3b5db57 Compare June 7, 2025 06:24

pbsds mentioned this pull request Jun 7, 2025

maintainers/scripts/remove-old-aliases: handle more complex cases #414664

Closed

13 tasks

pbsds requested a review from hsjobeki June 20, 2025 01:49

hsjobeki requested changes Jun 20, 2025

View reviewed changes

nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 1, 2025

This comment was marked as resolved.

Sign in to view

pbsds closed this Sep 14, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

aliases: warnOnInstantiate all aliases if `config.warnAliases=true`#414658

aliases: warnOnInstantiate all aliases if `config.warnAliases=true`#414658
pbsds wants to merge 2 commits intoNixOS:masterfrom
pbsds:feat-warn-aliases-1749253960

pbsds commented Jun 7, 2025 •

edited

Loading

Uh oh!

nixos-discourse commented Jun 11, 2025

Uh oh!

hsjobeki left a comment

Uh oh!

hsjobeki Jun 20, 2025 •

edited

Loading

Uh oh!

pbsds Jun 25, 2025 •

edited

Loading

Uh oh!

Pandapip1 commented Jul 21, 2025 •

edited

Loading

Uh oh!

mdaniels5757 commented Jul 21, 2025 •

edited

Loading

Uh oh!

This comment was marked as resolved.

Uh oh!

roberth commented Jul 21, 2025

Uh oh!

wolfgangwalther commented Sep 14, 2025

Uh oh!

pbsds commented Sep 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

pbsds commented Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Showcase:

Things done

Uh oh!

nixos-discourse commented Jun 11, 2025

Uh oh!

hsjobeki left a comment

Choose a reason for hiding this comment

Uh oh!

hsjobeki Jun 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pbsds Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pandapip1 commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mdaniels5757 commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

roberth commented Jul 21, 2025

Uh oh!

wolfgangwalther commented Sep 14, 2025

Uh oh!

pbsds commented Sep 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

pbsds commented Jun 7, 2025 •

edited

Loading

hsjobeki Jun 20, 2025 •

edited

Loading

pbsds Jun 25, 2025 •

edited

Loading

Pandapip1 commented Jul 21, 2025 •

edited

Loading

mdaniels5757 commented Jul 21, 2025 •

edited

Loading