Open Stack

On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft <donald at stufft.io> wrote:

>
> > On Feb 6, 2015, at 9:00 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> >
> > On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
> >> As part of oslo.messaging initiative to split up requirements into
> >> certain list of per messaging driver dependencies
> > [...]
> >
> > I'm curious what the end goal is here... when someone does `pip
> > install oslo.messaging` what do you/they expect to get installed?
> > Your run-parts style "requirements.d" plan is sort of
> > counter-intuitive to me in that I would expect it to contain
> > number-prefixed sublists of requirements which should be processed
> > collectively in an alphanumeric sort order, but I get the impression
> > this is not the goal of the mechanism (I'll be somewhat relieved if
> > you tell me I'm mistaken in that regard).
> >
> >> Taking into account suggestion from Monty Taylor i’m bringing this
> >> discussion to much wider audience. And the question is: aren’t we
> >> doing something complex or are there any less complex ways to
> >> accomplish the initial idea of splitting requirements?
> >
> > As for taking this to a wider audience we (OpenStack) are already
> > venturing into special snowflake territory with PBR, however
> > requirements.txt is a convention used at least somewhat outside of
> > OpenStack-related Python projects. It might make sense to get input
> > from the broader Python packaging community on something like this
> > before we end up alienating ourselves from them entirely.
>
> I’m not sure what exactly is trying to be achieved here, but I still assert
> that requirements.txt is the wrong place for pbr to be looking and it
> should
> instead look for dependencies specified inside of a setup.cfg.
>
> 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.
Inner  dependency - is a redirection from requirements.txt to another file
that contains additional dependencies (-r another_deps.txt)

> More on topic, I'm not sure what "inner" dependencies are, but if what
> you're
> looking for is optional dependencies that only are needed in specific
> situation
> then you probably want extras, defined like:
>
>     setup(
>         extras_require={
>             "somename": [
>                 "dep1",
>                 "dep2",
>             ],
>         },
>     )
>
>
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:

setup(
        extras_require={
            "somename": [
                "-r another_file_with_deps.txt",
            ],
        },
    )


> Then if you do ``pip install myproject[somename]`` it'll include dep1 and
> dep2
> in the list of dependencies, you can also depend on this in other projects
> like:
>
>     setup(
>         install_requires=["myproject[somename]>=1.0"],
>     )
>
>
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,
then he'd be able to install only that type of oslo.messaging that he wants
i.e.

project/requirements.txt:
...
oslo.messaging[amqp1]>=${version}

...

Really great input, thanks Donald. Appreciate it.

---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Kind regards,
Denis M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150206/a11fda0f/attachment.html>