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 <d...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev