[Distutils] Local version identifiers from PEP 440 in practice
Nick Coghlan
ncoghlan at gmail.com
Wed Dec 17 11:37:40 CET 2014
On 17 December 2014 at 13:31, Ethan Furman <ethan at stoneleaf.us> wrote:
> Oh, to be clear: There are no guarantees that 1.4 actually includes the bug-fixes in +debian1, correct? It's just a
> big hope?
Correct. The local versions were mostly added such that Linux distros
could indicate to Python specific tools when patches had been applied
using the distro packaging system. This is actually a pretty normal
practice (especially in a long lived distro like RHEL/CentOS - our
version numbers indicate the *baseline* version of a package), but
it's currently completely invisible to the Python level tooling (a
patched distro provided package will currently report the same Python
level version metadata as a pristine upstream package).
The promise we make is that any such patches shouldn't break
compatibility at all (that's the whole point of the baseline+backports
long term support model), which is why the comparison semantics are
defined to ignore them by default. That lets us incorporate security
fixes (for example) without breaking anything, while still providing
an indication that something has changed in the software.
Whether those patches make their way upstream will depend on the patch
and the upstream project. Some distro integration patches (like pip
dependency unbundling) will never go upstream. Others will be
backports of bug fixes from later upstream feature releases to earlier
versions that are integrated into the distro. And some will be patches
that distros apply because we need them quickly for some reason, and
then subsequently work through the process of getting the change (or a
variant thereof) accepted upstream (because carrying downstream
patches long term is expensive, we prefer not to do it if we don't
have to).
So while the usage model Maurits describes here is valid (and should
work with setuptools 8 + pip 6), it isn't really the primary intended
use case - it's aimed at when you're installing Python packages but
using something other than the Python specific tooling to do it (e.g.
apt-get, yum, conda, etc).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list