Open Stack

On 02/06/2015 10:12 AM, Doug Hellmann wrote:
> 
> 
> On Fri, Feb 6, 2015, at 07:37 AM, Denis Makogon wrote:
>> Hello to All.
>>
>>
>> As part of oslo.messaging initiative to split up requirements into
>> certain
>> list of per messaging driver dependencies
>> <https://review.openstack.org/#/c/83150/>
>>
>> it was figured that we need to find a way to use pip inner dependencies
>> and
>> we were able to do that, short info our solution and how it works:
>>
>>
>>
>>    - This is how regular requirements.txt looks:
>>
>> dep1
>>
>> …
>>
>> dep n
>>
>>
>>    - This is how looks requirements.txt with inner dependencies:
>>
>>     dep1
>>
>>     -r somefolder/another-requirements.txt
>>
>>     -r completelyanotherfolder/another-requirements.txt
>>
>>     …
>>
>>     dep n
>>
>> That’s what we’ve did for oslo.messaging. But we’ve faced with problem
>> that
>> was defined as openstack-infra/project-config
>>
>> tool issue, this tool called project-requirements-change
>> <https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/project-requirements-change.py>
>> .As you can see it’s not able to handle inner dependencies in any
>>
>> of requirements.txt files, as you can see this tool expects to parse only
>> explicit set of requirements (see regular requirements.txt definition
>> above).
>>
>> So, i decided to fix that tool to make it able to look over inner
>> dependencies, and here’s <https://review.openstack.org/#/c/153227/> what
>> i
>> have for yesterday,
>>
>> 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?
> 
> After re-reading this message, and discussing it with a few folks in the
> infra channel on IRC, I'm a little concerned that we don't have enough
> background to fully understand the problem and proposed solution. bnemec
> pointed out that the discussion happened before we had the spec process,
> but now that we do have that process I think the best next step is to
> have a spec written in oslo-specs describing the problem we're trying to
> solve and the approaches that were discussed. This may really just be
> summarizing the existing discussions, but let's get all of that
> information into a single document before we go any further.

For reference, here are the major discussions I'm aware of around this
issue:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026976.html

http://lists.openstack.org/pipermail/openstack-dev/2015-January/055229.html

https://bugs.launchpad.net/heat/+bug/1225191

https://bugs.launchpad.net/neutron/+bug/1225232

-Ben