[Distutils] setuptools passing arguments/settings to dependencies' dependencies

[Kent Bower]

On 5/7/2010 3:12 PM, P.J. Eby wrote:
>
> It's not the part where it deletes *their* file that I'm worried about 
> -- it's the people who might post such a thing to PyPI and delete 
> random strangers' configuration files, in response to running, say, 
> "setup.py --help".  (Which your code will do.)
>


Ok, now we understand one another.  This setuptools is very useful 
software even for cases where one has no intention of publicly releasing 
to PyPI.  I failed to communicate this is the case for me....


>
>>> I would be *extremely* upset if I tried to install your package and 
>>> it erased one of my .pydistutils.cfg files, with all their command 
>>> aliases, wikiup configs, path customizations, etc.
>>
>> (Again, for my project this is a non-issue, as our company installs 
>> our software on our client's VMs.)
>
> Right - as long as you never distribute your project to *anyone 
> else*.  Ever.
>
>
>>> (Of course, when run under easy_install control, the sandbox should 
>>> catch your setup script's antics and terminate it with an error 
>>> without harming any files, but still...  it's pure evil and the sort 
>>> of thing that should NEVER, ever be done in a setup.py, on pain of 
>>> banishment from PyPI.)
>> Hard to tell if you are saying that tongue-in-cheek, but if not, now 
>> you're being a bit harsh.  I am working around a problem that is a 
>> deficit in the tool (as far as I can determine).  In my circumstances 
>> what I am doing is perfectly acceptable and work-around of this 
>> nature are not "pure evil", it works and it may help someone else 
>> with exactly my issue, though it was rather amusing to read, just 
>> that I couldn't tell how serious you were being.
>
> I think perhaps you're misunderstanding me.  What I'm saying is that 
> anybody who knowingly uploads code like that to PyPI does indeed need 
> to be banned until they get the concept of not unconditionally 
> deleting users' configuration files in a setup.py.
>
> It's precisely this sort of behavior that easy_install's sandboxing 
> facility was added to prevent.
>


I was misunderstanding you, in fact, and I wholeheartedly agree, that 
would be evil (well, I don't know about "evil", but very wrong)... we 
are on the same page now.


> In any case, what I don't get is, if you're distributing this only to 
> your customers' VMs, why not just do one of the following:
>
> 1. Put the necessary settings in lib/distutils/distutils.cfg  
> (configure globally for the VM, in other words)
> 2. Put them in ~/.pydistutils.cfg to start with, and leave 'em there
> 3. Specify them explicitly on the command line (I assume you're not 
> having the users manually run setup.py install or easy_install, are you?)
>

#3 is exactly what I was trying to do... it doesn't work as of c11.

#1 or #2 were my next ideas, but I really want to support the 
installation on these machines in more than one directory so that, once 
in production, it is trivial to revert to a previous release simply by 
running from the old release directory.  Because of this, I cannot put 
an absolute path in lib/distutils/distutils.cfg or ~/.pydistutils.cfg 
because it changes relative to the thirdparty/ directory, which is 
relative to the location of setup.py.


> Don't get me wrong; if this behavior really changed between c9 and 
> c11, I would like to understand it myself.  What's weird is, it seems 
> to me that it should have either always worked or always not worked.  
> Although, it's possible that the way it was "working" in c9 was 
> actually a side-effect of a bug I know I fixed by c11, wherein 
> --find-links were sometimes being taken at too high a precedence -- 
> although, in that case, it would've only manifested in cases where the 
> installed version and the --find-links version were identical.
>
> The major thing that changed about dependency resolution by c11, is 
> that when a dependency is built, sys.path and the working_set are put 
> back the way they were before the build occurred, in order to prevent 
> certain kinds of potential recursive loops and "poisoning" of the 
> build environment.  However, the main install command should never 
> have been bothered by that in the first place, so I'm still having 
> trouble wrapping my head around what you're saying.  I'll probably 
> have to dig into the code more before I can get a clue on this one.
>