<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 6:09 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</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"><span class="">On 13 April 2015 at 12:53, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
<br>
> What we have in the gate is the thing that produces the artifacts that<br>
> someone installing using the pip tool would get. Shipping anything with<br>
> those artifacts other that a direct communication of what we tested is<br>
> just mean to our end users.<br>
<br>
</span>Actually its not.<br>
<br>
What we test is point in time. At 2:45 UTC on Monday installing this<br>
git ref of nova worked.<br>
<br>
Noone can reconstruct that today.<br>
<br>
I entirely agree with the sentiment you're expressing, but we're not<br>
delivering that sentiment today.<br>
<br>
We need to balance the inability to atomically update things - which<br>
forces a degree of freedom on install_requires - with being able to<br>
give someone the same install that we tested.<br>
<br>
That is the fundamental tension that we're not handling well, nor have<br>
I seen a proposal to tackle it so far.<br>
<br>
I'll have to spend some time noodling on this, but one of the clear<br>
constraints is that install_requires cannot both be:<br>
 - flexible enough to permit us to upgrade requirements across many<br>
git based packages [because we could do coordinated releases of sdists<br>
to approximate atomic bulk changes]<br>
 - tight enough enough to give the next person trying to run that ref<br>
of the package the same things we installed in CI.<br>
<br>
-> I think we need something other than install_requires<br>
<br>
...<br>
<span class="">> I disagree that anything is broken for us that is not caused by our<br>
> inability to remember that distro packaging concerns are not the same as<br>
> our concerns, and that the mechanism already exists for distro pacakgers<br>
> to do what they want. Furthermore, it is caused by an insistence that we<br>
> need to keep versions "open" for some ephemeral reason such as "upstream<br>
> might release a bug fix" Since we all know that "if it's not tested,<br>
> it's broken" - any changes to upstream software should be considered<br>
> broken until proven otherwise. History over the last 5 years has shown<br>
> this to be accurate more than the other thing.<br>
<br>
</span>This seems like a strong argument for really being able to reconstruct<br>
what was in CI.<br>
<span class=""><br>
> If we pin the stable branches with hard pins of direct and indirect<br>
> dependencies, we can have our stable branch artifacts be installable.<br>
> Thats awesome. IF there is a bugfix release or a security update to a<br>
> dependent library - someone can propose it. Otherwise, the stable<br>
> release should not be moving.<br>
<br>
</span>Can we do that in stable branches? We've still got the problem of<br>
bumping dependencies across multiple packages.<br></blockquote><div><br></div><div>We cannot do this today with 'pip install -r requirements.txt' but we can with 'pip install -r --no-deps requirements.txt'  if requirements includes all transitive dependencies. And then we have to figure out transitive dependencies for all projects etc. </div><div><br></div><div>What do you mean bumping dependencies across mulitple packages?</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">
<span class="im"><br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
</span><div class=""><div class="h5">__________________________________________________________________________<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>