The build option for C extension or not is taken directly from the setup.py of Genshi, the template language, and as I said was also inspired by what Storm does in this regard. I think once we put the flag on by default there really won't be any controversy anymore - both of those packages build the C extension by default.
It seems awkward that a source distribution (emphasis on the word "source") would be broken up into two among configuration options (not to mention it would be totally inconvenient on my side). What if our build had six flags, not two - would I then provide SQLAlchemy as six separate downloads on Pypi ? e.g. the source distro of the Python Imaging Library has a whole set of flags you can set within setup.py to assist in its location of libraries - there's not much getting around those at the level of the source distro - a source distribution only represents the source code, not its particular configuration in a particular environment. You may say these are all broken configurations, but the simple fact is that we talking about a source distribution, not a dpkg or rpm. When you get PIL as a dpkg on your Ubuntu system, its pre-configured for the correct locations of libjpeg and such. Its a problem that is solved by those packaging libraries but is not solved by Python source distros on Pypi. The setuptools analogue to dpkg and rpm, I think, would be an .egg file. If someone wants to distrbute SQLAlchemy in some kind of package oriented system with pre-selected options, outside the realm of well known unix package managers, they can always package it as such. On May 7, 2010, at 2:58 PM, Gaetan de Menten wrote: > 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 <k...@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 > _______________________________________________ > Distutils-SIG maillist - distutils-...@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
