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

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 https://github.com/abathur/flake_dream2nix_patchelf/commit/d5a0b66793d697342046f39bd9054b321e60765b with demonstration in CI at https://github.com/abathur/flake_dream2nix_patchelf/actions/runs/9470568588/job/26091792723#step:8:17
adding fix via https://github.com/abathur/flake_dream2nix_patchelf/commit/a9ed2275a9cc47e3610318860573cef6382a882d with demonstration in CI at https://github.com/abathur/flake_dream2nix_patchelf/actions/runs/9470810183/job/26092560974#step:8:16

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?

nix-community / dream2nix

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