<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 7:27 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Feb 20, 2015, at 06:06 AM, Sean Dague wrote:<br>
> On 02/20/2015 12:26 AM, Adam Gandelman wrote:<br>
> > Its more than just the naming.  In the original proposal,<br>
> > requirements.txt is the compiled list of all pinned deps (direct and<br>
> > transitive), while <a href="http://requirements.in" target="_blank">requirements.in</a> <<a href="http://requirements.in" target="_blank">http://requirements.in</a>> reflects<br>
> > what people will actually use.  Whatever is in requirements.txt affects<br>
> > the egg's requires.txt. Instead, we can keep requirements.txt unchanged<br>
> > and have it still be the canonical list of dependencies, while<br>
> > reqiurements.out/requirements.gate/requirements.whatever is an upstream<br>
> > utility we produce and use to keep things sane on our slaves.<br>
> ><br>
> > Maybe all we need is:<br>
> ><br>
> > * update the existing post-merge job on the requirements repo to produce<br>
> > a requirements.txt (as it does now) as well the compiled version.<br>
> ><br>
> > * modify devstack in some way with a toggle to have it process<br>
> > dependencies from the compiled version when necessary<br>
> ><br>
> > I'm not sure how the second bit jives with the existing devstack<br>
> > installation code, specifically with the libraries from git-or-master<br>
> > but we can probably add something to warm the system with dependencies<br>
> > from the compiled version prior to calling pip/<a href="http://setup.py/etc" target="_blank">setup.py/etc</a><br>
> > <<a href="http://setup.py/etc" target="_blank">http://setup.py/etc</a>><br>
><br>
> It sounds like you are suggesting we take the tool we use to ensure that<br>
> all of OpenStack is installable together in a unified way, and change<br>
> it's installation so that it doesn't do that any more.<br>
><br>
> Which I'm fine with.<br>
><br>
> But if we are doing that we should just whole hog give up on the idea<br>
> that OpenStack can be run all together in a single environment, and just<br>
> double down on the devstack venv work instead.<br>
<br>
</div></div>I don't disagree with your conclusion, but that's not how I read what he<br>
proposed. :-)<br>
<br></blockquote><div><br></div><div>Sean was reading between the lines here. We are doing all this extra work to make sure OpenStack can be run together in a single environment, but it seems like more and more people are moving away from deploying with that model anyway. Moving to this model would require a little more then just installing everything in separate venvs.  We would need to make sure we don't cap oslo libraries etc. in order to prevent conflicts inside a single service. And we would still need a story around what to do with stable branches, how do we make sure new libraries don't break stable branches -- which in turn can break master via grenade and other jobs. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Joe wanted requirements.txt to be the pinned requirements computed from<br>
the list of all global requirements that work together. Pinning to a<br>
single version works in our gate, but makes installing everything else<br>
together *outside* of the gate harder because if the projects don't all<br>
sync all requirements changes pretty much at the same time they won't be<br>
compatible.<br>
<br>
Adam suggested leaving requirements.txt alone and creating a different<br>
list of pinned requirements that is *only* used in our gate. That way we<br>
still get the pinning for our gate, and the values are computed from the<br>
requirements used in the projects but they aren't propagated back out to<br>
the projects in a way that breaks their PyPI or distro packages.<br>
<br>
Another benefit of Adam's proposal is that we would only need to keep<br>
the list of pins in the global requirements repository, so we would have<br>
fewer tooling changes to make.<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
>       -Sean<br>
><br>
> --<br>
> Sean Dague<br>
> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
<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>