[openstack-dev] Moving forward with openstack/requirements

Monty Taylor mordred at inaugust.com
Sun Jan 13 03:30:04 UTC 2013


Hey all!

Once again, we've kind of stalled out on our two-summit old project of
common requirements across the projects. The initial repo is up at
http://github.com/openstack/requirements but I think not much happens
with it because working on it doesn't really get you anything right now.

So I've got an idea for steps to move forward.

Step 0: Re-sync the contents of the files with the new state of reality
Step 1: Drive updates to the OpenStack PyPI mirror from the requirements
repo
Step 2: Configure the Jenkins slaves to only talk to the PyPI mirror for pip
Step 3: Add a step to the pypi mirror creation that pulls packages fresh
from requirements into a new proposed state of the PyPI mirror, then
tests all of the projects against that mirror and only promotes new
packages into if those tests pass.

That's it. Done.

If we do through step 2, it means that before someone can add a new
requirement to a project, it would have to go into
openstack/requirements. If we do step 3, it'll trap for things like the
sqlalchemy 0.8 upgrade issue. It also, as an approach, doesn't enforce
that projects have to upgrade at any point, because previous versions of
things will still be in our mirror (we don't purge it)

Also - while you're all thinking about it - I've been considering
getting the code we have in oslo-incubator setup that makes setup.py
understand pip-requires and test-requires automatically upstreamed
(seems like a thing we're not the only ones who would want it) The catch
- those aren't the filenames most people use for those files. SO - what
if we (and by we, I mean I, and by I, I mean a shell script that submits
a bajillion reviews) renamed tools/pip-requires to requirements.txt and
tools/test-requires to test-requirements.txt? I've already updated our
mirror creation code to recognize both files. If people are cool with
that, I can then work on trying to get a patch into distribute that
would allow for that - which would mean less copied code for us.

Thoughts welcome...

Monty



More information about the OpenStack-dev mailing list