[openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py
clay.gerrard at gmail.com
Thu Jul 30 01:12:37 UTC 2015
I agree an error message is better than breaking for insane reasons.
But... maybe as an aside... what about not breaking?
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)?
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."
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.
On Wed, Jul 29, 2015 at 10:27 AM, Robert Collins <robertc at robertcollins.net>
> Similar to pbr, we have a minimum version of setuptools required to
> consistently install things in OpenStack. Right now thats 17.1.
> However, we don't declare a setup_requires version for it.
> I think we should.
> setuptools can't self-upgrade, and we don't have declarative deps yet,
> so one reaction I expect here is 'how will this help'.
> The problem lies in the failure modes. With no dependency declared,
> setuptools will try and *silently fail*, or try and fail with this one
> weird error - that doesn't say anything about 'setuptools 3.3. cannot
> handle PEP 426 version markers'.
> If we set a minimum (but not a maximum) setuptools version as a
> setup_requires, I think we'll signal our actual dependencies to
> redistributors, and folk consuiming python packages, in a much more
> direct fashion. They'll still have to recover manually, but thats ok
> IMO. As long as we don't set upper bounds, we won't deadlock ourselves
> like we did in the past.
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev