<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 5:54 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Feb 6, 2015, at 09:56 AM, Denis Makogon wrote:<br>
> On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> ><br>
> > > On Feb 6, 2015, at 9:00 AM, Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
> > ><br>
> > > On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:<br>
> > >> As part of oslo.messaging initiative to split up requirements into<br>
> > >> certain list of per messaging driver dependencies<br>
> > > [...]<br>
> > ><br>
> > > I'm curious what the end goal is here... when someone does `pip<br>
> > > install oslo.messaging` what do you/they expect to get installed?<br>
> > > Your run-parts style "requirements.d" plan is sort of<br>
> > > counter-intuitive to me in that I would expect it to contain<br>
> > > number-prefixed sublists of requirements which should be processed<br>
> > > collectively in an alphanumeric sort order, but I get the impression<br>
> > > this is not the goal of the mechanism (I'll be somewhat relieved if<br>
> > > you tell me I'm mistaken in that regard).<br>
> > ><br>
> > >> Taking into account suggestion from Monty Taylor i’m bringing this<br>
> > >> discussion to much wider audience. And the question is: aren’t we<br>
> > >> doing something complex or are there any less complex ways to<br>
> > >> accomplish the initial idea of splitting requirements?<br>
> > ><br>
> > > As for taking this to a wider audience we (OpenStack) are already<br>
> > > venturing into special snowflake territory with PBR, however<br>
> > > requirements.txt is a convention used at least somewhat outside of<br>
> > > OpenStack-related Python projects. It might make sense to get input<br>
> > > from the broader Python packaging community on something like this<br>
> > > before we end up alienating ourselves from them entirely.<br>
> ><br>
> > I’m not sure what exactly is trying to be achieved here, but I still assert<br>
> > that requirements.txt is the wrong place for pbr to be looking and it<br>
> > should<br>
> > instead look for dependencies specified inside of a setup.cfg.<br>
> ><br>
> > Sorry, i had to explain what i meant by saying 'inner dependency'. Let me<br>
> be more clear at this step to avoid misunderstanding in terminology.<br>
> Inner  dependency - is a redirection from requirements.txt to another<br>
> file<br>
> that contains additional dependencies (-r another_deps.txt)<br>
><br>
> > More on topic, I'm not sure what "inner" dependencies are, but if what<br>
> > you're<br>
> > looking for is optional dependencies that only are needed in specific<br>
> > situation<br>
> > then you probably want extras, defined like:<br>
> ><br>
> >     setup(<br>
> >         extras_require={<br>
> >             "somename": [<br>
> >                 "dep1",<br>
> >                 "dep2",<br>
> >             ],<br>
> >         },<br>
> >     )<br>
> ><br>
> ><br>
> That might be the case, but since we want to split up requirements into<br>
> per-driver dependecies, it would require to check if setup.cfg can handle<br>
> use of inner dependencies. for example:<br>
><br>
> setup(<br>
>         extras_require={<br>
>             "somename": [<br>
>                 "-r another_file_with_deps.txt",<br>
>             ],<br>
>         },<br>
>     )<br>
<br>
</div></div>Let's see if we can make pbr add the extras_require values. We can then<br>
either specify the requirements explicitly in setup.cfg, or use a naming<br>
convention for separate requirements files. Either way, we shouldn't<br>
need setuptools to understand that we are managing the list of<br>
requirements in files.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>That might be the case. And probably PBR is the only place where we can <br>place that logic since distutils already can do that.<br></div><div> <br></div><div>Doug, i will take a look at PBR and will try to figure out the easiest way to get extras_require into it. Thanks for input.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
><br>
> > Then if you do ``pip install myproject[somename]`` it'll include dep1 and<br>
> > dep2<br>
> > in the list of dependencies, you can also depend on this in other projects<br>
> > like:<br>
> ><br>
> >     setup(<br>
> >         install_requires=["myproject[somename]>=1.0"],<br>
> >     )<br>
> ><br>
> ><br>
> That's i've been looking for, so, for future installations it'll be very<br>
> useful if cloud deployer knows which AMQP service will be used,<br>
> then he'd be able to install only that type of oslo.messaging that he<br>
> wants<br>
> i.e.<br>
><br>
> project/requirements.txt:<br>
> ...<br>
> oslo.messaging[amqp1]>=${version}<br>
><br>
> ...<br>
><br>
> Really great input, thanks Donald. Appreciate it.<br>
><br>
> ---<br>
> > Donald Stufft<br>
> > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
> ><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> Kind regards,<br>
> Denis M.<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Kind regards,<br>Denis M.<br><br></div><div class="gmail_extra"><br></div></div>