Treewide: change all occurrences of "name" to "pname-version"

[AndersonTorres]

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[AndersonTorres]

Related issue: #103997

[siraben]

Is it expected that none of these derivations will build differently because the interpolated strings are the same as they were before?

[AndersonTorres]

Yes. It is just a rewriting of the expressions.

[SuperSandro2000]

Unrelated to this PR but the platform should probably be set to x84_64 only.

[SuperSandro2000]

This should probably use fetchFromGitHub.

[AndersonTorres]

It would change the final output. I am not trying to do this here and now.

[SuperSandro2000]

Suggested change

	url = "mirror://sourceforge/mp3gain/${pname}-1_6_2-src.zip";
	url = "mirror://sourceforge/mp3gain/${pname}-${builtins.replaceStrings ["."] ["_"] version}-src.zip";

I did not test this.

[doronbehar]

This is also out of scope for this PR.

[Atemu]

Doesn't eval for the most part.

Fix: https://github.com/AndersonTorres/nixpkgs/pull/1

[Atemu]

With my changes, Nixpkgs can be eval'd again and the sources that aren't already broken still produce the same output.

Also, nit: Treewide -> treewide

[AndersonTorres]

Oh man, this will not be easy.

There are many "legitimate" uses of namein Nixpkgs, in the sense that merely changing a single file from name to pname-version triggers auxiliary functions defined elsewhere - and these functions use name!

[doronbehar]

I think it's impossible for this to not trigger rebuilds since even in the simplest case, the builder gets after this change the new environment variable pname and version which weren't there before and unfortunately (without structuredAttrs I suppose) it's a change in the inputs.

[AndersonTorres]

@doronbehar : then, in a certain sense, the expression itself becomes a "build input" of itself?

And what is structuredAttrs?

Well, in this sense I think we can sprint it to the next viable update.

[doronbehar]

And what is structuredAttrs?

#72074 && https://nixos.mayflower.consulting/blog/2020/01/20/structured-attrs/

@doronbehar : then, in a certain sense, the expression itself becomes a "build input" of itself?

I'm not sure I understand your explanation, but to demonstrate how easily rebuilds can be triggered, consider a change such as:

diff --git i/pkgs/development/compilers/gcc/9/default.nix w/pkgs/development/compilers/gcc/9/default.nix
index 305ed56df78..e39c787284b 100644
--- i/pkgs/development/compilers/gcc/9/default.nix
+++ w/pkgs/development/compilers/gcc/9/default.nix
@@ -83,6 +83,7 @@ in
 stdenv.mkDerivation ({
   pname = "${crossNameAddon}${name}${if stripped then "" else "-debug"}";
   inherit version;
+  dummyVar = "bla";
 
   builder = ../builder.sh;
 

That would rebuild the world, and you can see that via running nix show-derivation -f. gcc.cc before and after the change, and inspect the diff in a text editor.

The difference between the derivations can be found in the env attribute of the derivations, where the dummyVar environment variable which you and I know that won't affect the build is the culprint, but Nix doesn't know it.

In general nix show-derivation -f. is the judge, though ofborg has a more sophisticated way of doing that in a batch.

What's so frustrating about it is that our default-builder.sh and most of it's derivatives handle the conditionals which ideally should have been evaluated by Nix. A real world examples of such unnecessary rebuilds triggered is (only the Darwin rebuilds of) e.g: #94952 (comment) .

Even changes in the order of inputs in a Nix arrays causes rebuilds, consider this change:

diff --git i/pkgs/development/compilers/gcc/9/default.nix w/pkgs/development/compilers/gcc/9/default.nix
index 305ed56df78..d73089e9c0c 100644
--- i/pkgs/development/compilers/gcc/9/default.nix
+++ w/pkgs/development/compilers/gcc/9/default.nix
@@ -168,7 +168,7 @@ stdenv.mkDerivation ({
     ++ optional targetPlatform.isLinux patchelf;
 
   buildInputs = [
-    gmp mpfr libmpc libelf
+    mpfr gmp libmpc libelf
     targetPackages.stdenv.cc.bintools # For linking code at run-time
   ] ++ (optional (isl != null) isl)
     ++ (optional (zlib != null) zlib)

It will also trigger a rebuild of the world.

The problem is that mkDerivation doesn't know how to filter out the unnecessary information for our default-builder.sh though I can't think of a better way to design it.

---

structuredAttrs could perhaps allow us to write a default-builder.sh that will hopefully be resilient to this false interpretations of changed inputs.

[jtojnar]

@doronbehar order of build inputs matters since it can change the order setup hooks are run and we cannot guarantee arbitrary bash code commutes. Another example where it is a problem are environment variables like PKG_CONFIG_PATH – when multiple different derivations contain the same library, the first one found in the PKG_CONFIG_PATH will be chosen. I routinely encounter this when overriding subset of dependencies with enableDebugging, especially when dependency propagation comes into play.

[FRidh]

This should not be merged until consensus is found in #103997.

[AndersonTorres]

This is just a parallel work for now, and way far from a clear finish.

Anyway I will treat this as Draft for now.

[AndersonTorres]

Another day, another huma nerror. Now I will try to recover.

EDIT: is the interface broken? I can't reopen this!

[Atemu]

GH thinks you force-pushed to a commit already in master and, since that means there are no changes, won't let you open the PR.

Should work again if you push another commit.

Would probably also not be a bad idea to simply push commits and then squash them up once they're ready. Following changes between force-pushes isn't really something you can do very well in git.

[SuperSandro2000]

Would probably also not be a bad idea to simply push commits and then squash them up once they're ready. Following changes between force-pushes isn't really something you can do very well in git.

Not true as long as you don't do a rebase in the same force push. https://github.com/NixOS/nixpkgs/compare/32986af10085058e08125720467d84f5e1afe4b3..712c2405b1c4ddf461a1eafd640165583d1c0cca

[AndersonTorres]

Reopening
#104662