Excerpts from 7c6f434c's message of Wed Dec 22 19:41:41 +0100 2010: > >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.
Usually I'm willing to accept compromises. In this case its not worth because the patch + allows scons to work out of the box on nixos * there is no penalty other than you have to interpret the scons documeantion in a clever way (reading [/bin/... ] as "allowing finding items you installed using package management tools) If I compare this to: - introduce NIX_SCONS_PATH (- because complexity increases much more) - users have to look it up - nix derivations have to set it => lot's of bloat for no reason So for me its no option. If we go the complicated way for "documentation" reasons which are subject for discussion anyway and where no use case exists I can't appreciate it. We should strive hard for overall simplicity if possible. Marc Weber _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
