>> That is, most of the tools provided by stdenv. This way, we actually get >> *more* >> predictable behaviour than upstream, so it's at least in the spirit of the >> upstream behaviour of not using the caller's environment. What do you think? >I've had the issue that gcc wasn't found. So it would have solved my issue. >However you know that in nixpkgs you're likely to override gcc. If you >hardcode gcc it won't work as expected in all cases. >So you fix something and you add potential breakage.
Now that you write that, I see the disaster potential in this. We could always say that stdenv should be overriden in a deep way, but that doesn't feel right to me, neither. >So what could be done ? Should we introduce PATH_STANDARD_TOOLS (which >can't be defined) but which could be used instead? KISS (keeping things >stupid simple is most important). So I still vote for my patch. But I >have it applied anyway. So its up to you to judge. Well, if we want a nixy solution, maybe the wrapper (or even the expression itself) should notice NIX_SCONS_PATH and use it instead of PATH. Anyone who set it in user environment did it deliberately. And then we can write a trivial setup-hook. Peter, is that behaviour of using our unique environment variable with the intent to set it only during Nix builds or when user _wants_ non-default behaviour acceptable for you? Maybe we could do without an extra wrapper. Personally I do think that having /usr/bin in Scons path in NixPkgs is suboptimal on non-NixOS systems; PATH is manageable to track, and NIX_SCONS_PATH seems to be a middle ground. >The patch was very long on the mailinglist. That feedback was given that >late illustrates that the current workflow of submitting patches works >but is not perfect. Its also you (the cummunity) who has to decide >whether you want this kind of "commit -> revert" or "commit -> fix" >history more often than necessary. I think marking patches with expression name in the very beginning of the topic ([SCONS][Nix-dev] ...) can help people notice the patches, but I also think that sometimes discussions die away before all sides have explained their positions in enough detail - and that is suboptimal.. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
