current `dontStrip = true` default causes some python packages to hold on to GCC as a runtime dependency

[abathur]

Just opening this to document trouble I had in case it helps someone save a few days of flailing--I don't have enough perspective on what kinds of problems were caused by stripping to understand which default is ideal.

Hodgepodge of observations in case they make this more searchable:

• In the process of switching a project over from mach-nix to dream2nix, I noticed that a container containing the environment generated with dockerTools.buildLayeredImage was nearly twice as large as the old mach-nix-based container.
• I added the environment to the new container by including packages.blah.pyEnv in its contents.
• Unpacking the container filesystem and fishing around led me to identify the most-conspicuous difference as the presence of GCC.
• Using nix-tree on it (I needed something like nix build .#blah && nix run github:nixos/nixpkgs#nix-tree -- --dot .#blah helped identify 5 packages as depending on GCC: libsass, misaka, psycopg2 rjsmin, sqlalchemy.
• After a good bit of flailing about with override mechanisms, I eventually tracked this down by expanding my search beyond dream2nix stuff and finding a discourse thread where the same basic problem (unexpected runtime dependency on GCC) was identified as a side-effect of stripping being disabled. #673 disabled stripping by default here.
• I ended up getting what I need with pip.overrideAll.mkDerivation.dontStrip = false;, but overriding this on the individual problem-packages also worked just fine if you need to be more precise (i.e., pip.overrides.misaka.mkDerivation.dontStrip = false;).

Since I extracted a minimal reproducible example in the process of figuring this out, I'll include links in case they help (ignore the repo name, I added it on top of a repro for a different problem I had):

• adding a package that holds on to GCC via abathur/flake_dream2nix_patchelf@d5a0b66 with demonstration in CI at https://github.com/abathur/flake_dream2nix_patchelf/actions/runs/9470568588/job/26091792723#step:8:17

• adding fix via abathur/flake_dream2nix_patchelf@a9ed227 with demonstration in CI at https://github.com/abathur/flake_dream2nix_patchelf/actions/runs/9470810183/job/26092560974#step:8:16

[abathur]

It's a tangent, but one bit of this does still puzzle me if anyone knows what's missing from my mental model.

When I do something like nix run github:nixos/nixpkgs#nix-tree -- --dot .#blah | grep misaka I'll see:

...
  "python3.9-misaka-2.1.1" -> "gcc-13.2.0" [];
  "python3.9-misaka-2.1.1" -> "glibc-2.39-31" [];
  "python3.9-misaka-2.1.1" -> "python3.9-cffi-1.16.0" [];
  "python3.9-misaka-2.1.1" -> "bash-5.2p26" [];
  "python3.9-misaka-2.1.1" -> "python3.9-cffi-1.16.0" [];
  "python3.9-misaka-2.1.1" -> "python3.9-pycparser-2.22" [];
  "python3.9-misaka-2.1.1" -> "glibc-2.39-31-dev" [];
  "python3.9-misaka-2.1.1" -> "python3-3.9.19" [];
...

But then if I just do, say, nix run github:nixos/nixpkgs#nix-tree -- --dot .#prod.pyEnv.pkgs.misaka | grep misaka l only see:

  "python3.9-misaka-2.1.1" -> "glibc-2.39-31" [];
  "python3.9-misaka-2.1.1" -> "python3.9-cffi-1.16.0" [];
  "python3.9-misaka-2.1.1" -> "bash-5.2p26" [];
  "python3.9-misaka-2.1.1" -> "python3.9-pycparser-2.22" [];
  "python3.9-misaka-2.1.1" -> "python3-3.9.19" [];

Anyone know why the latter doesn't indicate the same dependency on GCC as the former?