[Distutils] inability to pass setup.py command line arguments to dependency setups
kb at retailarchitects.com
Fri May 7 19:56:41 CEST 2010
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
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.
More information about the Distutils-SIG