Interesting, is that supported in pbr (since this is whats being used in this situation at least for requirements).
-----Original Message----- From: David Koo <kpublicm...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Wednesday, February 12, 2014 at 7:35 PM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [All]Optional dependencies and requirements.txt > >> Most of the reason for the #2 there is for plugins that taskflow can >> use (but which are not required for all users). Ideally there would be >> more dynamic way to list requirements of libraries and projects, one >> that actually changes depends on the features used/desired to be used. > >Disclaimer: Not a pip/setuptools developer - only a user. > >From the pip & setuptools docs, the "extras" feature[1] of these tools >seems to do what you want: > > SQLAlchemy<=0.7.99,<=0.9.99 [SQLAlchemyPersistence] > alembic>=0.4.1 [SQLAlchemyPersistence] > ... > >[1] http://www.pip-installer.org/en/1.1/requirements.html > >-- >Koo > >On Thu, 13 Feb 2014 02:37:44 +0000 >Joshua Harlow <harlo...@yahoo-inc.com> wrote: > >> In taskflow we've done something like the following. >> >> Its not perfect, but it is what currently works (willing to take >> suggestions on better). >> >> We have three different requirements files. >> >> 1. Required to work in any manner @ >> https://github.com/openstack/taskflow/blob/master/requirements.txt 2. >> Optionally required to work (depending on features used) @ >> >>https://github.com/openstack/taskflow/blob/master/optional-requirements.t >>xt >> 3. Test requirements (only for testing) @ >> https://github.com/openstack/taskflow/blob/master/test-requirements.txt >> >> Most of the reason for the #2 there is for plugins that taskflow can >> use (but which are not required for all users). Ideally there would >> be more dynamic way to list requirements of libraries and projects, >> one that actually changes depends on the features used/desired to be >> used. In a way u could imagine a function taking in a list of desired >> features (qpid vs rabbit could be one such feature) and that function >> would return a list of requirements to work with this feature set. >> Splitting it up into these separate files is doing something similar >> (except using static files instead of just a function to determine >> this). I'm not sure if anything existing (or is planned) for making >> this situation better in python (it would be nice if there was a way). >> >> -Josh >> >> From: Doug Hellmann >> <doug.hellm...@dreamhost.com<mailto:doug.hellm...@dreamhost.com>> >> Reply-To: "OpenStack Development Mailing List (not for usage >> questions)" >> >><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.o >>rg>> >> Date: Wednesday, February 12, 2014 at 1:42 PM To: Ben Nemec >> <openst...@nemebean.com<mailto:openst...@nemebean.com>>, "OpenStack >> Development Mailing List (not for usage questions)" >> >><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.o >>rg>> >> Subject: Re: [openstack-dev] [All]Optional dependencies and >> requirements.txt >> >> >> >> >> On Wed, Feb 12, 2014 at 3:58 PM, Ben Nemec >> <openst...@nemebean.com<mailto:openst...@nemebean.com>> wrote: Hi all, >> >> This is an issue that has come up recently in tripleo as we try to >> support more varied configurations. Currently qpid-python is not >> listed in requirements.txt for many of the OpenStack projects, even >> though they support using Qpid as a messaging broker. This means >> that when we install from source in tripleo we have to dynamically >> add a line to requirements.txt if we want to use Qpid (we pip install >> -r to handle deps). There seems to be disagreement over the correct >> way to handle this, so Joe requested on my proposed Nova change that >> I raise the issue here. >> >> There's already some discussion on the bug here: >> https://bugs.launchpad.net/heat/+bug/1225191 as well as a separate >> Neutron bug here: https://bugs.launchpad.net/neutron/+bug/1225232 >> >> If there's a better alternative to "require all the things" I'm >> certainly interested to hear it. I expect we're going to hit this >> more in the future as we add support for other optional backends for >> services and such. >> >> We could use a separate requirements file for each driver, following >> a naming convention to let installation tools pick up the right file. >> For example, oslo.messaging might include amqp-requirements.txt, >> qpid-requirements.txt, zmq-requirements.txt, etc. >> >> That would complicate the global requirements sync script, but not >> terribly so. >> >> Thoughts? >> >> Doug >> >> >> >> Thanks. >> >> -Ben >> >> _______________________________________________ >> OpenStack-dev mailing list >> >>OpenStack-dev@lists.openstack.org<mailto:openstack-...@lists.openstack.or >>g> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
