<br><br><div class="gmail_quote">On Sat, Jan 12, 2013 at 10:30 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all!<br>
<br>
Once again, we've kind of stalled out on our two-summit old project of<br>
common requirements across the projects. The initial repo is up at<br>
<a href="http://github.com/openstack/requirements" target="_blank">http://github.com/openstack/requirements</a> but I think not much happens<br>
with it because working on it doesn't really get you anything right now.<br>
<br>
So I've got an idea for steps to move forward.<br>
<br>
Step 0: Re-sync the contents of the files with the new state of reality<br>
Step 1: Drive updates to the OpenStack PyPI mirror from the requirements<br>
repo<br>
Step 2: Configure the Jenkins slaves to only talk to the PyPI mirror for pip<br>
Step 3: Add a step to the pypi mirror creation that pulls packages fresh<br>
from requirements into a new proposed state of the PyPI mirror, then<br>
tests all of the projects against that mirror and only promotes new<br>
packages into if those tests pass.<br></blockquote><div><br></div><div>It could also use a pip/tox cache directory for those tests to avoid complicating the PyPI setup.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
That's it. Done.<br>
<br>
If we do through step 2, it means that before someone can add a new<br>
requirement to a project, it would have to go into<br>
openstack/requirements. If we do step 3, it'll trap for things like the<br>
sqlalchemy 0.8 upgrade issue. It also, as an approach, doesn't enforce<br>
that projects have to upgrade at any point, because previous versions of<br>
things will still be in our mirror (we don't purge it)<br></blockquote><div><br></div><div>This improves the situation, but doesn't quite solve the problem of rolling out updates to packages where we are pegged to a specific version (see the recent thread on WebOb). Step 3 is really important for being able to switch from == versioning to the more flexible >= versioning.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also - while you're all thinking about it - I've been considering<br>
getting the code we have in oslo-incubator setup that makes setup.py<br>
understand pip-requires and test-requires automatically upstreamed<br>
(seems like a thing we're not the only ones who would want it) The catch<br>
- those aren't the filenames most people use for those files. SO - what<br>
if we (and by we, I mean I, and by I, I mean a shell script that submits<br>
a bajillion reviews) renamed tools/pip-requires to requirements.txt and<br>
tools/test-requires to test-requirements.txt? I've already updated our<br>
mirror creation code to recognize both files. If people are cool with<br>
that, I can then work on trying to get a patch into distribute that<br>
would allow for that - which would mean less copied code for us.<br></blockquote><div><br></div><div>+1</div><div><br>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Thoughts welcome...<br>
<br>
Monty<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br>