config.allowAliases: add NIXPKGS_ALLOW_ALIASES to have an easy way to

[Artturin]

disable aliases regardless of where nixpkgs is imported

i think one of the reasons we have many alias usages in nixpkgs is because it's not easy to disable aliases

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[roberth]

Suggested change

	defaultText = literalExpression ''builtins.getEnv "NIXPKGS_ALLOW_ALIASES" == "1" || true'';
	defaultText = literalMD ''`true` unless `getEnv "NIXPKGS_ALLOW_ALIASES" == "0"`'';

[roberth]

i think one of the reasons we have many alias usages in nixpkgs is because it's not easy to disable aliases

OfBorg is currently counterproductive for at least two alias problems.

1. Flag deprecation warnings as errors
2. Allow the use of aliases internally in Nixpkgs

Where (2) makes (1) even worse.

Issue:

• Always evaluate with config.allowAliases = false to avoid deprecation warning errors ofborg#575

[roberth]

I am not a big fan of environment variables in Nix expressions actually. This one is not as bad as NIXOS_EXTRA_MODULE_PATH (:nauseated_face:), and I can be pragmatic, but I'd like someone else to have a look as well.

[teto]

i think one of the reasons we have many alias usages in nixpkgs is because it's not easy to disable aliases

Isn't it for backwards compatibility or to help the user find packages more easily ? as such there is little incentive to disable aliases (why would you ?). I think it's just a matter of people not knowing about it, rather than not knowing how to disable.

I am also not very enthusiast of adding new environment variables.

[roberth]

Indeed the existence of aliases is a good thing, and so is even the use of aliases by third party* code, because it improves the range of compatibility.

That said, new names exist for a reason, and Nixpkgs is not third party code.
Also, over time it's good to move people over to new names for consistency. We need more sinceRelease, which facilitates a deprecation cycle.

(I hope my lecture wasn't too off-topic :))

* third party meaning: not Nixpkgs, not the configuration author, but another source such as home-manager, nixos-hardware, or nixos-mailserver.

[SuperSandro2000]

as such there is little incentive to disable aliases (why would you ?).

If you contribute regularly you want to have them disabled to not get reminded about them from ofborg.

Also ofborg does not check for them in unfree packages which can lead to surprising breakes.

---

An easy way to turn them of is to add { allowAliases = false; } to ~/.config/nixpkgs/config.nix and run with --impure.

[SuperSandro2000]

IMO we should use some library function which accepts 0, 1, true, false, TRUE, True, FALSE and False just to make it easy for everyone.