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

[Gaetan de Menten]

FWIW, it is perfectly possible to package the thing separately as
Glyph seem to suggest, even if the feature is enabled through an
option. For example, Debian does it:
http://packages.debian.org/experimental/python-sqlalchemy-ext

On Fri, May 7, 2010 at 19:56, Kent Bower <kb at retailarchitects.com> wrote:
> 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.

-- 
Gaëtan de Menten