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