On May 7, 2010, at 1:56 PM, Kent Bower wrote: > (I don't appreciate the aggressive tone of your reply, though, nor do I see > how my good faith efforts to help others warrant this... how did I possibly > offend you with my post??)
Let me start here to set the tone: Please note that I am not attacking _you_. I thought that this was pretty clear, but if anything I said (in either my previous message or this one) could be construed as a personal attack, then I sincerely apologize: that was not and is not my intention. If anything, I'm grateful to you for bringing this up, and giving me a clear example to express my views on this issue, so they are recorded for future askers of similar questions. I'm enthusiastically attacking your *proposed feature*, because I think it's a terrible idea that will cause lots of problems if implemented, but I don't believe you suggested it in bad faith or have otherwise malicious intent. > Just because there are configuration problems associated with adding a > feature like the one I needed is absolutely no reason to abandon it when it > can bring value to the tool if used correctly and in some circumstances. Here's a somewhat exaggerated example. It may be convenient for some people, in some circumstances, to attach an exposed lawnmower blade to a child's toy. Maybe they're out playing with their kids and want to mow the lawn at the same time: if the toys are also all lawnmowers, it's super convenient. And there's of course no problem if this feature is used correctly, in the right circumstances: by adults, carefully, to mow lawns. However, most toy manufacturers would agree that it is not worth the risk of taking off a child's hands or head to provide someone with that additional convenience. If you want a lawnmower, buy a lawnmower and use it to mow your lawn. Don't go welding exposed blades to every available household object that may be at hand when you're in your yard. > I considered some of those exact complications "what if it was already > installed, etc" and with my company's project, where I am using this useful > tool in a circumstance you may overlook (it is perfectly acceptable to have > such a feature, *despite* the list of complications you mention), such a > feature would have been very valuable. In your particular case, what you're trying to do is deploy an application, not express code dependencies. While I haven't used Buildout personally, my understanding is that this is the sort of thing that Buildout is intended to do: deploy a specific application with specific dependencies in a carefully-controlled environment. I have no idea if Buildout can do precisely what you want, but if not, there are plenty of other tools which do similar things: makefiles, shell scripts, fabric, capistrano... and each of these tools let you encode that consideration that you've done in a dedicated place, rather than injecting it somewhere it doesn't belong (your application logic, your setup.py). The risk here, which I am keen to avoid, is that if you provide the ability to pass command line arguments via setup.py, people will start uploading packages that do that to PyPI. Gradually, half of your dependencies will start wanting to pass conflicting sets of "helpful" options to their dependencies at installation time, and getting your library packages installed will be an even bigger mess than it is right now. For the most part, distutils needs *fewer* knobs that developers and packagers can turn; this is not one of the few places where it needs more. See all the recent work that's gone into statically expressing all dependencies in a data format, without even having a setup.py. This is a manifestation of a social problem in open source projects; rather than fix a problem correctly, there is a temptation to say "just let me pass through my options so it works for me". If you want to depend on C extensions in SQLAlchemy, there should be a proper way to do that so that it works regardless of what other packages you happen to have installed or how they got there. (See "standing up to user pressure", here: <http://ometer.com/free-software-ui.html>.) > On the other hand, I appreciate your "correct solution" as a good approach > and I'll forward this idea to an author of SQLAlchemy for his consideration. Thanks. Good luck getting that fix in! :)
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
