[Distutils] inability to pass setup.py command line arguments to dependency setups

[Kent Bower]

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.  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.

Since it is useful in my case, I understand it would be valuable for 
others as well.

(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??)

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.


On 5/7/2010 1:33 PM, Glyph Lefkowitz wrote:
> On May 7, 2010, at 9:09 AM, Kent wrote:
>
>    
>> Consider the case where you want your setup to install third-party
>> software, but you want/need to pass an argument to the command line
>> that runs "python setup.py --argument install" or "python setup.py --
>> argument bdist_egg"
>>
>> As far as I could research, this feature is unavailable.
>>      
> And for good reason, I should think.  I really hope that nobody ever adds this feature.
>
> If you require SQLAlchemy to be installed "--with-cextensions", then what happens when your package is installed in an environment that already has SQLAlchemy installed *without* that flag?  Does it stomp on the existing installation?  What if the user installed one already with that flag and some other flags as well?  What if it's system-installed and you're doing a user-install?
>
> Basically, compile-time and install-time options are a configuration nightmare.  They should represent only how and where a package is installed, not what features it has. The correct solution to your problem would be to get SQLAlchemy to fix its broken deployment setup and split itself into 2 packages, "SQLAlchemyCExtensions" and "SQLAlchemy", and then have your project depend on both, not to try to cram installer options into the dependency language.
>
> For confirmation of this theory, you need look no further than the excruciating user-experience of source-based installation systems with 'variant' support, like gentoo's Portage and *BSD's Ports, versus the relatively non-excruciating experience of packaging systems which express compile-time options as different packages like Yum and Apt.
>
>