Overriding stdenv to change gcc in buildPythonPackage

If I have a python package derivation like

{ buildPythonPackage
, fetchPypi
...
}:
buildPythonPackage {
    pname = ...;
}

Which I’m trying to use it in a big environment python38.withPackages(ps: with ps; [ numpy my-package-from-above ... ])

Is it possible to override the stdenv just for that package? Specifically I’d like to compile this package with a different version of gcc while not messing with the other packages in the environment?

Should be able to override the version on the root python interpreter, but may run into with python packages inheriting stdenv from the root pkgs.

too be completely safe, you need to to do an overlay with:

final: prev {
  stdenv = gccXStdenv;
}

however, you will probably have to build everything from stdenv, which will take a while.

Or some how override the pkgs which gets passed when creating the package set might also be another option.

I have run into this issue, and it feels like it should be fixable. It is pretty easy to override stdenv for the python interpreter itself:

nix-shell -E 'with import <nixpkgs> {}; (python310.override { stdenv = clangStdenv;})'

but this doesn’t prapogate to anything in python310.pkgs. Looking at the definition of buildPythonPackage, this may just be a matter of adding stdenv as an argument to mk-python-derivation.nix and overriding the correct top level attribute (seems like maybe pythonInterpreters?)

I will explore a bit this weekend, but if anyone does know the correct way to do this, let us know! There are some straight up native package in the python package set (e.g pybind11) where is is pretty important that we can override stdenv

Given the current state of overriding, i think the only way to do this easily is to override stdenv for all of nixpkgs as jon suggested. Not sure if you can actually do this with an overlay because of infinite recursion issues, but you can do

import <nixpkgs> { config.replaceStdenv = ( { pkgs }: pkgs.clangStdenv; )}

There are a lot of people thinking about how to fix overriding for nixpkgs, so hopefully one day, we will be able to do this for specific packages in package sets