[Nix-dev] Re: [PATCH 1/2] t/scons
7c6f434c at mail.ru
7c6f434c at mail.ru
Wed Dec 22 19:41:41 CET 2010
>> 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..
More information about the nix-dev
mailing list