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

[7c6f434c at mail.ru]

>7c6f434c at mail.ru,
>
> > And you haven't given an example where you need scons to ignore PATH,
> > unfortunately.
>
>I have explained the rationale behind my preference for the unmodified
>SCons behavior in quite some detail. I have made an effort to take any
>and all postings in this thread seriously, to respond to them, and to
>address the issues that are being raised to the best of my abilities
>given the usual time constraints that apply to contributors to a free
>software project. I have tried really hard to figure out what I can do
>to serve everyone's best interest.

I have explained why the rationale is context-dependent. So, when we
have questionable context (SCons relies on FHS, and we have no FHS),
it is nice to see concrete use cases.

>Now, when I look at the list of people who have contributed to SCons in
>the past, I see this:
>
> | /usr/local/src/nixpkgs-current$ git log --pretty=short pkgs/development/tools/build-managers/scons | git shortlog
> | eelco (6):
> |       * Added the build manager SCons.
> |       * Copy a bunch of files to nix.cs.uu.nl.
> |       * Reverted r6713, r6711, r4623, r3660, r2237.  There rewrote fetchurl
> |       * Rewrite all the SourceForge URLs to mirror://sourceforge/.
> |       * Merged the stdenv branch
> |       * Fix an infinite recursion in scons.
> |
> | raskin (1):
> |       Python must be propagatedBuildInputs now that they are using env
 
As you see, I am simply interested in fixing unintuitive gotchas..

> | roconnor (1):
> |       Patching scons to give an absolute path to python rather than using ".../bin/env python"
> |
> | simons (11):
> |       scons: updated to version 0.95.5 and added selectVersion dispatcher
> |       scons: install library files in python's site-package directory
> |       Cosmetic, no functional change intended.
> |       Updated scons and twisted; added buildbot.
> |       Updated scons to version 1.2.0.
> |       scons: don't overwrite a pre-existing PYTHONPATH in the wrapper
> |       pkgs/development/tools/build-managers/scons: bumped to version 1.3.0
> |       Moved 'maintainers' attribute into the meta section of the expression.
> |       pkgs/development/tools/build-managers/scons: updated to version 2.0.1
> |       pkgs/development/tools/build-managers/scons: move --mandir and --infodir to standard locations
> |       pkgs/development/tools/build-managers/scons: cosmetic build improvements
>
>Eelco and I have both stated that we would prefer Marc's patch not be
>applied to the standard SCons expression. We have both explained our
>reasons for that opinion, and we've also tried to offer alternative
>solutions that address your concerns in another way. Yet, after having
>written over a dozen postings or so, here you are outright demanding
>that I deliver even further explanations before you are satisfied! WTF?
>
>All I here from you, from Kevin, and from Marc are wild unsubstantiated
>claims about how the world is going to come to an end unless we modify
>SCons, even though the package has worked just fine without those
>modifications for the last 5 years! Frankly, you are the ones who demand
>an extremely intrusive change to SCons, so the burden of proof is on
>*you*.

It is not about sky falling on the earth, it is about the new behaviour 
being better - taking into account the facts about NixOS
that are false about other distributions and taking into account complex
to understand mistakes one can make with hardcoding paths into Scons. 

Marc has stumbled upon a place where this is a problem. I don't want
more people stumbling upon the very same problem. It's not about sky
falling.

The sky hasn't fallen because of double-opt-in scheme with parallel building,
it is just suboptimal.

>Unfortunately, you choose not to reveal your real name, so I can't be
>sure, but as far as I can tell, your posting from Dec 22 was the first
>time ever you said anything on this mailing list. The first posting from

Michael Raskin _is_ my real name, I am just too lazy to configure current 
mail client. You can check stdenv.lib.maintainers for this email address.

And I use the same email 7c6f434c at mail.ru for every posting to this list.

>Kevin is dated Jan 2nd. Apparently, both of you are somewhat new to this

I am not that new to the project. But this adds nothing to my arguments. 
I agree that it would be strange if this discussion was really my _first_ 
e-mail to nix-dev. It is not.

>project. Still, here you are lecturing us about how we have no idea how
>stuff is supposed to work in NixOS.

I say that the reasoning is based on strange basis - I periodically package
things using, well, different build systems, and so adding a compilcation 
to remember when packaging one in twenty of scons-based projects is something
I want some pragmatic reason for. I didn't stumble upon this myself yet - 
but I do not want MarcWeber's stumbling upon this fact to be lost with no 
lasting improvement of ease of packaging.

Michael Raskin