At 01:36 PM 5/7/2010 -0400, Kent Bower wrote:
Like I mentioned, I do have a workaround in place that is working for me. I post it here in case it may help others:
Please don't do that, and *nobody else should do it either*. You are going to ERASE people's personal distutils configuration files with that code! (You're not even checking to see if it exists first!)
Thank you for posting the disclaimer before use. I am exactly aware it is deleting that file and for my project that is completely acceptable, so I did not do anything fancy like backing it up. I'd hope anyone using this would have an understanding of python enough to see what is going on and modify it to meet their needs, but that is a poor assumption so a disclaimer would have been better; thank you for posting such.
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.)
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. 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?) 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.