Open Stack

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.

> 
> 
> > 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