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

[Kevin Quick]

On Mon, 03 Jan 2011 07:02:18 -0700, Peter Simons <simons at cryp.to> wrote:

> Hi Kevin,
>
>  >> The exact list of paths would be passed to the expression as a
>  >> parameter, so that these settings can be overridden easily. That
>  >> would allow us to instantiate many different variants of scons that
>  >> use different tools by default.
>  >
>  > This [doesn't work] if you are simply running it in a dev tree for a
>  > local project that does not have a nix derivation.
>
> it appears that you have misunderstood how that solution would work. You
> seem to assume that SCons would be passed a search path every time it is
> run. In fact, however, SCons would be passed that search path at the time
> SCons itself is being built. Those paths are subsequently hard-coded into
> the SCons binary to ensure that they are set every time SCons is run.

Hi Peter,

Hmm... not sure I follow you entirely.  Let me try restating things a little to make sure we're converging:

* 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.

* Eelco proposed changing it so that the internal path searching was set to a set of core tools when SCons was installed.

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) although using $HOME/.nix-profile/bin would be more in line with the SCons repeatability determinism.  In this situation there would be no path list provided to SCons invocations.

Eelco's proposal is IMHO awkward for a personal development tree because (1) I need some way to pass a list of derivations that should be included in SCons's internally-set path, and (2) I have to rebuild scons each time I want to add/remove/update a tool (which is very non-intuitive).

I believe Eelco's proposal *is* valid for a nix-derivation using an SCons-based build method because you want to explicitly control what tools SCons uses rather than the current user's set of paths.  That's why I propose defaulting to $HOME/.nix-profile/bin (a tweak of Marc's patch) but having some mechanism for overriding this for a nix build (perhaps similar to Rob's mething of using importenv on the command-line).

> This
> solution guarantees deterministic behavior regardless of whether SCons is
> being run from Nix or from any other context. In particular, you'd be free
> to configure SCons to search for tools in "$HOME/.nix-profile/bin", which is
> what you suggested.

Deterministic but minimal until the user educates themselves and starts providing lots of path information to the SCons build.  I'd advocate the approach of "enabled-by-default" to get the best useability experience (i.e. things should just work for the Nix noobs like me :-).

>
> In other words, the solution Eelco proposed can trivially emulate yours, but
> your suggestion cannot emulate Eelco's. Consequently, the approach suggested
> above seems to be strictly more powerful, and thus preferable.

[I assumed "above" referenced Eelco's proposal.]

Perhaps there could be an "scons.path.explicit" setting in the config file that would switch from the "enabled-by-default" to only what's specified on the "scons.path.list" line.  That would provide the best of both approaches, with the "easy on the noob" the default approach but the "explicit" approach being available as well for power Nix users.

Regards,
-KQ

> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>


-- 
-KQ