[Distutils] setuptools passing arguments/settings to dependencies' dependencies
kb at retailarchitects.com
Fri May 7 21:55:01 CEST 2010
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.
More information about the Distutils-SIG