Open Stack

On Fri, Feb 6, 2015 at 5:54 PM, Doug Hellmann <doug at doughellmann.com> wrote:

>
>
> On Fri, Feb 6, 2015, at 09:56 AM, Denis Makogon wrote:
> > 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",
> >             ],
> >         },
> >     )
>
> Let's see if we can make pbr add the extras_require values. We can then
> either specify the requirements explicitly in setup.cfg, or use a naming
> convention for separate requirements files. Either way, we shouldn't
> need setuptools to understand that we are managing the list of
> requirements in files.
>
>
That might be the case. And probably PBR is the only place where we can
place that logic since distutils already can do that.

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.

>
> >
> > > 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.
> >
> __________________________________________________________________________
> > 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
>
> __________________________________________________________________________
> 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/398d322e/attachment.html>