@teh, thanks for your PR! By analyzing the annotation information on this pull request, we identified @abbradar, @FRidh and @domenkozar to be potential reviewers

I like the idea of being able to add other paths, so +1 for that.

However, I am not sure what the right solution is. In this case, Theano needs gcc. We've added stdenv to propagatedBuildInputs, but its not available with python.buildEnv because we filter out the non-Python packages. Furthermore, gcc is not on the PATH of the interpreter either.

Should we actually filter non-Python packages in the first place? The purpose of the buildEnv is that the binaries (including interpreter) can find all Python libraries and therefore all it needs to do is to wrap the binaries setting PYTHONHOME I don't see any point in the filtering. @bennofs, what do you think?

@FRidh I'm not sure, but not filtering the results of closePropagation sounds dangerous to me... it seems like that could add a lot of paths to the buildEnv. Not sure if that is actually a concern in practice though.

@bennofs actually, I think it won't. While with Python packages we use propagatedBuildInputs a lot, that is not the case with other dependencies. Those are most often only build dependencies and therefore wouldn't show up in the env.

I wasn't sure either but with the current attempts to keep closure size small (for docker etc) I thought it might be easier for people to build explicit envs over having everything in propagatedBuildInputs

#18696 should work now for you.

In retrospect I don't think #18696 was such a good idea and am leaning more to this original PR instead. We've begun using buildEnv more now in Nixpkgs, and I've seen cases where the eventual environment got quite big as.

Also, @teh, in your case the proper solution is to patch Theano to hardcode the path to g++ / clang++.
Its a matter of adding at default value right here and removing the whole param stuff above it.

@FRidh - thanks. Let me know if you want me to rebase or just do the change yourself.

no longer valid