<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><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>
</span>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 should<br>
instead look for dependencies specified inside of a setup.cfg.<br>
<br></blockquote><div>Sorry, i had to explain what i meant by saying 'inner dependency'. Let me be more clear at this step to avoid misunderstanding in terminology.<br></div><div>Inner  dependency - is a redirection from requirements.txt to another file that contains additional dependencies (-r another_deps.txt)<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
More on topic, I'm not sure what "inner" dependencies are, but if what you're<br>
looking for is optional dependencies that only are needed in specific 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></blockquote><div><br>That might be the case, but since we want to split up requirements into per-driver dependecies, it would require to check if setup.cfg can handle use of inner dependencies. for example:<br><br><div style="margin-left:40px">setup(<br>
        extras_require={<br>
            "somename": [<br></div></div><div style="margin-left:40px">
                "-r another_file_with_deps.txt",<br></div><div><div style="margin-left:40px">
            ],<br>
        },<br>
    )<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Then if you do ``pip install myproject[somename]`` it'll include dep1 and 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></blockquote><div><br></div><div>That's i've been looking for, so, for future installations it'll be very 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 wants i.e.<br><br></div><div>project/requirements.txt:<br>...<br></div><div>oslo.messaging[amqp1]>=${version}<br><br>...<br><br></div><div>Really great input, thanks Donald. Appreciate it.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
---<br>
Donald Stufft<br>
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<div class=""><div class="h5"><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></div><div class="gmail_extra"><br></div></div>