Open Stack

Sounds good to me Doug. +1 for a spec since this will affect every project.

-- dims

On Fri, Feb 6, 2015 at 11:12 AM, Doug Hellmann <doug at doughellmann.com> 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.
>
> Doug
>
>>
>>
>> Kind regards,
>>
>> Denis M.
>>             IRC: denis_makogon at Freenode
>> __________________________________________________________________________
>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims