<div dir="ltr"><div>I agree an error message is better than breaking for insane reasons.</div><div><br></div><div>But... maybe as an aside... what about not breaking?</div><div><br></div>How come the openstack ecosystem doesn't have wait for PEP 426 to be approved and for setuptools 17.1 to be widely deployed before it can require/depend on it?  Is there no failure/degraded case where we can take advantage of moving forward in the infrastructure where we apparently need it - but not necessarily force everyone else to upgrade if it's not directly solving something for them (e.g. people doing packaging of openstack projects, but don't personally necessarily currently maintain or distribute a setuptools package)?<div><br></div><div>On the web this happens all the time "Sure maybe you can't get the newest HTML5 wiz-bang, but I can still render something on IE8, OTOH, IE7, wow - pls upgrade" vs. "How are you not even running setuptools 17.1 right now in your build environment - it was *literally* released *almost* two months ago!?  I... I can't even... it hurts to look at you."</div><div><br></div><div>Just Curious.</div><div><br></div><div>I only recently found out that PEP 426 was a thing, so I think it's pretty great to see people driving the python packaging ecosystem forward.  For those involved.  Kudos.</div><div><br></div><div>-Clay</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 29, 2015 at 10:27 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Similar to pbr, we have a minimum version of setuptools required to<br>
consistently install things in OpenStack. Right now thats 17.1.<br>
<br>
However, we don't declare a setup_requires version for it.<br>
<br>
I think we should.<br>
<br>
setuptools can't self-upgrade, and we don't have declarative deps yet,<br>
so one reaction I expect here is 'how will this help'.<br>
<br>
The problem lies in the failure modes. With no dependency declared,<br>
setuptools will try and *silently fail*, or try and fail with this one<br>
weird error - that doesn't say anything about 'setuptools 3.3. cannot<br>
handle PEP 426 version markers'.<br>
<br>
If we set a minimum (but not a maximum) setuptools version as a<br>
setup_requires, I think we'll signal our actual dependencies to<br>
redistributors, and folk consuiming python packages, in a much more<br>
direct fashion. They'll still have to recover manually, but thats ok<br>
IMO. As long as we don't set upper bounds, we won't deadlock ourselves<br>
like we did in the past.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>