[Nix-dev] Re: [PATCH 1/2] t/scons

[Kevin Quick]

On Wed, 05 Jan 2011 04:35:39 -0700, Peter Simons <simons at cryp.to> wrote:

> Hi Kevin.
>
>  > * Marc's patch updated the installed SCons so that when run it would
>  >   automatically read the user's PATH env variable for its internal
>  >   path searching.
>
> Yes. Please note that this patch has been superfluous from the very
> beginning, because SCons doesn't have to be patched to accomplish that.
> Marc has admitted himself that this patch is unnecessary.

Peter,

Not true!  The stock SCons specifically does NOT use the user's PATH variable and instead uses a hard-coded set: '/usr/local/bin:/opt/bin:/bin:/usr/bin'.   Take a look at Marc's patch.  It's needed because that hard-coded set is completely invalid on a system like NixOS that doesn't follow the FHS (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard).

Out of the box, on a user's dev tree, SCons will fail under NixOS where it succeeds under any FHS-conformant system.  Marc and I are proposing that this is a bad user experience and not helpful for NixOS.

And Marc did not "admit that this patch is unecessary".  He said:

    "So I still vote for my patch. But I have it applied anyway. So its up to you to judge."

>  > * Eelco proposed changing it so that the internal path searching was
>  >   set to a set of core tools when SCons was installed.
>
> No. Eelco rejected Marc's patch, and in the same posting went on to
> point out that the default path list hard-coded into SCons is useless on
> NixOS, because the directories /usr/local/bin, /usr/bin, and /bin don't
> exist in our environment. To improve matters, he suggested replacing the
> default path list with a set of paths that roughly corresponds to
> "stdenv" in NixOS.

But my assertion is that this is not helpful.  Eelco's path would be for specific components added as part of the nixos-rebuild and therefore only cover things in the system profile.

Consider for example if I have a project that uses SCons to build and needs to use some unusual tool (e.g. noweb, the D compiler, tinyCC, or anything else not considered part of the base system and it's services.  In a conventional system a "# sudo rpm -i noweb" would be sufficient to make noweb available for SCons.  Under NixOS, the user would type "$ nix-env -i noweb", but this would be futile as noweb would not be part of the preset paths for SCons.

The noweb addition *would* be part of $HOME/.nix-profile/bin, which is what I'm proposing as the adjustment to Marc's patch.  Actually, based on a separate thread it should probably be $HOME/.nix-profile/bin:/var/run/current-system/sw/bin.

> Now, it might look like that suggestion would be
> related to Marc's patch because it's been raised in the context of that
> discussion, but the two topics are orthogonal, really. No-one has
> suggested that Marc's patch be replaced by something else, because
> Marc's patch was unnecessary to begin with. There's no need to replace
> it with anything.

As I stated above, I disagree that Marc's patch is unrelated and believe that all of this is related under the topic of "make SCons useable for NixOS".


>  > I believe that Marc's patch is along the right direction for using
>  > SCons in a personal development tree (i.e. outside of a nix
>  > derivation) [...]
>
> That may or may not be true, but the fact of the matter is that this
> question is irrelevant in the context of NixOS. The authors of SCons
> have made the conscious decision to ignore the contents of $PATH. It's
> not our place to revert that decision, because NixOS is a
> *distribution*. We didn't write SCons, we just distribute it. If you
> would like to change SCons default behavior, then you are talking to the
> wrong group of people. Instead, you should be talking to the authors of
> SCons.

I believe I already pointed out why SCons doesn't use $PATH.  However, they clearly developed for an LHS layout for any system that claims to be "posix".  They also coded for other layouts on other systems (windows, darwin, etc.).  Clearly they intended that SCons should work in multiple environments.

I agree that this group is responsible for NixOS and not SCons development, but since NixOS has deviated from LHS then the responsibility for that deviation lies more with this group than it does with developers of independent tools.  I know that NixOS's focus is purity of the tree rather than broad adoption but I don't see that as a reason to be antagonistic to various tools or potential adopters.


>
> If you would like SCons to use $PATH to find build tools, then you can
> do that in numerous ways. The documentation recommends adding the lines
>
>   import os
>   env = Environment(ENV = {'PATH' : os.environ['PATH']})
>
> to the SConsfile, which sounds reasonable enough. Furthermore, you are
> absolutely welcome create a patched version of SCons in Nix that behaves
> the way you want it to, but please don't call it "scons". Instead, call
> it "scons-patched" or whatever, so that other users have the chance to
> distinguish your version from the pristine one.

None of these solutions help people who wish to use SCons under NixOS.  Existing packages that work universally will break under NixOS.  Every derivation will require a patch.  Every local dev tree will require a patch or a local commit (with ensuing conflicts down the line).  I believe that (a) few people will know to look for documentation on the above and be motivated to make the associated changes, (b) few projects are likely to accept patches to add the above PATH, (c) few people will wish to spend the time maintaining a private fork patch for SCons to make it
work differently, especially considering that they will *still* have to modify projects to invoke the "new" scons.

I further believe that (a), (b), and (c) are not beneficial to NixOS.

>
> Personally, I believe that SCons made a mistake when they provided any
> default search path *at all*. The default environment ought to be empty,
> really. I realize, though, that other people prefer things differently,
> and so I refrain from forcing my preferred view on everyone else.
> Instead, I make the necessary changes in my local nixpkgs tree. I would
> respectfully request that you and Marc and everyone else who wants SCons
> to behave differently than it does to do the same: please make those
> changes in such a way that your preferred solution isn't forced on me.

Actually, it sounds like there are at least three people in this discussion that do use SCons and would prefer a fix.  You have raised objections based on a philosophy of purity and what you believe should have been done by the SCons developers, but it's not clear that you actually use SCons and would be significantly affected by the outcome either way.  I would actually suggest that since your opinions differ from the (admittedly small) majority of this discussion as well as the SCons project itself that the modification methods you suggest above would be more appropriate for you to make to your own personal environment.

Or, as Marc said:

     "I wished Peter would have given a real use case - because I had one.
      This makes me shut up and change my mind fastest.

      ... I'm fighting for the vision "let's serve real world use cases trying to
      minimize the overall code base if reasonable" rather than abstract
      things."

I agree.  I, too, have a real use case.  One that cost me a couple of hours when I decided to try NixOS.  I think we should avoid re-applying that cost factor to every potential NixOS adopter who uses SCons (or any other valid tool).

Regards,

-- 
-KQ