<HTML>
<HEAD>
<TITLE>Re: [Openstack] Single global dependency list</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Ack, please don’t keep on adding on to the copy around stuff scheme. Pleaaaase :-)<BR>
<BR>
Is the devstack dependency list complete, when I created the anvil one, I found more than one hole...<BR>
<BR>
Also the devstack one is in a micro-format, maybe we can move to say, YAML?<BR>
<BR>
How about hosting these requires on some website (with versions there)? <BR>
<BR>
Github already provides this for the anvil dependency list, maybe that (or something) similar is sufficent?<BR>
<BR>
On 7/2/12 3:40 PM, "Monty Taylor" <<a href="mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hey all!<BR>
<BR>
One of the tasks from the last ODS was to implement a single global<BR>
dependency list. Turns out the more you think about it, the more<BR>
important it is... because of the way we use devstack as part of the<BR>
gate, we actually _currently_ have a de facto global dependency list,<BR>
it's just not declared anywhere. (oops)<BR>
<BR>
Anyway - the original thought was to put the depends in<BR>
openstack-common. We'd use update.py to copy the depends in to the<BR>
project, so that projects could align on their own timeframe.<BR>
Additionally, we'd make the copy only copy in the versions from<BR>
openstack-common for package that were already listed in the target<BR>
project, so that we wouldn't add django to python-swiftclient, for instance.<BR>
<BR>
The mechanics of that all work and are ready - but then bcwaldon pointed<BR>
out that it didn't make a ton of sense for them to go in<BR>
openstack-common, since that has its own lifecycle and is a place for<BR>
common code to go - not just a catch all place.<BR>
<BR>
To that end, I took the code we had written for the update logic and put<BR>
it, along with the depends lists, into its own repo. I think we're ready<BR>
to start actually moving forward with it - but we've run up against the<BR>
hardest problem we every have:<BR>
<BR>
naming<BR>
<BR>
openstack-depends already got vetoed on IRC because it makes people<BR>
think of adult diapers. I'm proposing openstack-requires, since the<BR>
files we're talking about are actually python requirements files.<BR>
<BR>
Any objections?<BR>
<BR>
We've also been discussing an idea that we could write some gating tests<BR>
that are only run against milestone-proposed branches that would verify<BR>
that the requires files in a given project match the versions in<BR>
openstack-requires - that way there is some lee-way throughout the<BR>
cycle, but the expectation is that by release time the requires files<BR>
will be brought in line with the rest of the project. (it's an option if<BR>
people find that useful - certainly not required)<BR>
<BR>
Finally, as an added bonus to this approach, once we have the list and<BR>
we're even mostly aligned on it, since a library version would need to<BR>
be in openstack-requires before it hits a project, we can use it as the<BR>
main basis for our pypi mirror and turn off the upstream pypi source<BR>
from our jenkins slaves. This would remove the last of the ephemeral<BR>
build errors that are due to upstream network timeouts. I'm sure<BR>
everyone will be pleased about that.<BR>
<BR>
Anyway - I think general buy in on at _least_ the name<BR>
openstack-requires will let us move forward with the next step. After<BR>
that point, it'll all be normal code reviews.<BR>
<BR>
Monty<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>