[sqlalchemy] Re: [Distutils] inability to pass setup.py command line arguments to dependency setups
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. -- 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.
Re: [sqlalchemy] Re: [Distutils] inability to pass setup.py command line arguments to dependency setups
I'd only mention that Storm has a C extension/non C extension flag as well, and only offers one source distribution on Pypi. You have to modify a variable directly within setup.py. Our setup.py features the same capability (its just our C extension is off by default for 0.6 since it was just written, which is the same case for when Storm first introduced its C extension). On May 7, 2010, at 1:56 PM, Kent Bower 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. -- 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. -- 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.
[sqlalchemy] Re: [Distutils] inability to pass setup.py command line arguments to dependency setups
Mike, Can I just take a second to thank you for your patience in running this forum? There are so many rude, arrogant software developers, and you seem to not be like them at all. Thanks. -- 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.
Re: [sqlalchemy] Re: [Distutils] inability to pass setup.py command line arguments to dependency setups
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.
