<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>We can side step the dependency graphing and ordering issue by looking at the list of curently installed packages via pip freeze and not installing dependencies (pip install --no-deps)</div><div><br></div>After looking into this further here are the known issues:<div><br></div><div>* Partial capping won't work [0], so we need to pin all dependencies, we can generate this list per file via "pip install -r" and "pip freeze", but this doesn't address the issue of apt-get vs pip install. For example in the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.</div><div>* Not all packages are installed in are standard dsvm-tempest env, so using pip-freeze from that isn't enough</div><div>* We need to run this per requirements file and move to using pip install --no-deps everywhere. As the global-requirements sync wouldn't work the first time since files don't list all transient dependencies yet.</div><div>* We can still break if a package version is removed from pypi</div><div>* in pip-freeze we sometimes install versions lower then our minimum version (python-libvirt!)</div><div><br></div></div></blockquote><div><br></div><div>Exploring a few ideas here: <a href="https://review.openstack.org/#/c/147451/4">https://review.openstack.org/#/c/147451/4</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html</a></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:<br>
[...]<br>
<span>> The other thing that happened was partial capping doesn't work,<br>
> because something else moves forward and breaks you from below. So<br>
> the patch will need to hit everything at once.<br>
<br>
</span>Right, and we _have_ to start using stable branches on all<br>
clients/libraries to backport fixes as part of that. This means that<br>
the stable branch management workflow is about to become pervasive<br>
across some teams who were previously (blissfully?) ignorant of it.<br>
<span><br>
> Unresolved entirely is the tertiary dependencies (not direct<br>
> dependencies of any OpenStack project). That will need another<br>
> mechanism to seed them before any installation happens.<br>
</span>[...]<br>
<br>
I won't go so far as to call it intractable, but I took a stab at it<br>
about a year ago and building the dependency graph properly to be<br>
able to do a depth-first ordering is nontrivial (enough that after<br>
about a week hacking on possible solutions I gave up and switched to<br>
more productive tasks). The primary complications I ran into were<br>
identifying setup_requires in transitive dependencies and dealing<br>
with platform/version-specific dependencies. That said, there's a<br>
very good chance that more recent improvements in setuptools, pip<br>
and virtualenv could make this task easier.<br>
<span><br>
> That's the things I can think off from the top of my head.<br>
<br>
</span>The implementation, from a devstack-gate perspective, is also going<br>
to require a decision on whether we stick with stable/relname for<br>
branches of libraries too or switch to some extended branch mapping<br>
mechanism to be able to track stable/relnum branches for those. And<br>
we're going to need more jobs to ensure that clients (specifically)<br>
retain backward-compatibility from an appdev and end user<br>
perspective since they'll no longer get any testing as server<br>
dependencies on stable branches (due to being capped there).<br>
<span><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>