<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-19 23:10 GMT+08:00 Clark Boylan <span dir="ltr"><<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote:<br>
> Hoy,<br>
><br>
> So Gnocchi gate is all broken (agaiiiin) because it depends on "pbr" and<br>
> some new release of oslo.* depends on pbr!=2.1.0.<br>
><br>
> Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0<br>
> that got in banished by requirements Gods. It does not prevent it to be<br>
> used e.g. to install the software or get version information. But it<br>
> does break anything that is not in OpenStack because well, pip installs<br>
> the latest pbr (2.1.0) and then oslo.* is unhappy about it.<br>
<br>
</span>It actually breaks everything, including OpenStack. Shade and others are<br>
affected by this as well. The specific problem here is that PBR is a<br>
setup_requires which means it gets installed by easy_install before<br>
anything else. This means that the requirements restrictions are not<br>
applied to it (neither are the constraints). So you get latest PBR from<br>
easy_install then later when something checks the requirements<br>
(pkg_resources console script entrypoints?) they break because latest<br>
PBR isn't allowed.<br>
<br></blockquote><div>  What we disscuss here is the way to avoid break things,  not sure  we<br></div><div> add pbr into  periodic-**-with-oslo-master works in <a href="https://review.openstack.org/458753">https://review.openstack.org/458753</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We need to stop pinning PBR and more generally stop pinning any<br>
setup_requires (there are a few more now since setuptools itself is<br>
starting to use that to list its deps rather than bundling them).<br>
<span class="gmail-"><br>
> So I understand the culprit is probably pip installation scheme, and we<br>
> can blame him until we fix it. I'm also trying to push pbr 2.2.0 to<br>
> avoid the entire issue.<br>
<br>
</span>Yes, a new release of PBR undoing the "pin" is the current sane step<br>
forward for fixing this particular issue. Monty also suggested that we<br>
gate global requirements changes on requiring changes not pin any<br>
setup_requires.<br>
<span class="gmail-"><br>
> But for the future, could we stop updating the requirements in oslo libs<br>
> for no good reason? just because some random OpenStack project hit a bug<br>
> somewhere?<br>
><br>
> For example, I've removed requirements update on tooz¹ for more than a<br>
> year now, which did not break *anything* in the meantime, proving that<br>
> this process is giving more problem than solutions. Oslo libs doing that<br>
> automatic update introduce more pain for all consumers than anything (at<br>
> least not in OpenStack).<br>
<br>
</span>You are likely largely shielded by the constraints list here which is<br>
derivative of the global requirements list. Basically by using<br>
constraints you get distilled global requirements and even without being<br>
part of the requirements updates you'd be shielded from breakages when<br>
installed via something like devstack or other deployment method using<br>
constraints.<br>
<span class="gmail-"><br>
> So if we care about Oslo users outside OpenStack, I beg us to stop this<br>
> crazyness. If we don't, we'll just spend time getting rid of Oslo over<br>
> the long term…<br>
<br>
</span>I think we know from experience that just stopping (eg reverting to the<br>
situation we had before requirements and constraints) would lead to<br>
sadness. Installations would frequently be impossible due to some<br>
unresolvable error in dependency resolution. Do you have some<br>
alternative in mind? Perhaps we loosen the in project requirements and<br>
explicitly state that constraints are known to work due to testing and<br>
users should use constraints? That would give users control to manage<br>
their own constraints list too if they wish. Maybe we do this in<br>
libraries while continuing to be more specific in applications?<br>
<span class="gmail-"><br>
><br>
> My 2c,<br>
><br>
> Cheers,<br>
><br>
> ¹ Unless some API changed in a dep and we needed to raise the dep,<br>
> obviously.<br>
><br>
> --<br>
> Julien Danjou<br>
> # Free Software hacker<br>
> # <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
<br>
</span>I don't have all the answers, but am fairly certain the situation we<br>
have today is better than the one from several years ago. It is just not<br>
perfect. I think we are better served by refining the current setup or<br>
replacing it with something better but not by reverting.<br>
<br>
Clark<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>ChangBo Guo(gcb)</div></div></div>
</div></div>