[Python-ideas] Add support for version objects

[Nick Coghlan]

On 28 May 2016 3:36 am, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 28 May 2016 at 05:38, Ethan Furman <ethan at stoneleaf.us> wrote:
> > On 05/27/2016 08:22 PM, Nick Coghlan wrote:
> >
> >> The main advantage I'd see to stdlib inclusion is providing "one
obvious
> >> way to do it" - it isn't immediately obvious to a newcomer that PEP 440
> >> and the implementation in packaging are the preferred approach for
> >> SemVer-like version numbers in Python projects.
> >
> >
> > Yup, I'll second that!
>
> Agreed. Having a version object in the stdlib would be a good way of
> directing people to the standard approach. Some points:
>
> - It pretty much has to be PEP 440, as that's the standard in the
> Python packaging ecosystem. Adding a *different* standard to the
> stdlib would be a big problem IMO.
> - Packaging tools like pip will still need to bundle an external
> implementation (at the moment we use the "packaging" library) as
> they'll need to support older versions of Python for some time yet. So
> there would need to be a maintained backport version on PyPI (or the
> packaging library could be sanctioned as that backport).
> - Assuming a separate backport, it's not clear to me how we'd manage
> the transition between packaging and the backport (maintain the 2 in
> parallel? packaging falls back to the stdlib/backport if present?
> packaging gains a conditional dependency on the backport?)
> - PEP 440, and the implementation, is pretty stable. But are we happy
> for it to move to the development pace of the stdlib?

The other issue is the intended use case - I *think* PEP 440 (including the
normalisation steps) will cover the version numbering for external
dependencies like Tkinter and zlib, but it's not the precise context that
spec was designed to cover (i.e. versioning distribution packages for
Python projects).

I still think the idea is worth considering, it's just a more complex
problem than it appears to be at first glance.

Cheers,
Nick.

>
> The distutils version classes are pretty old, and fairly limited - the
> strict version is frequently *too* strict, but the loose version is
> rather too lenient...
>
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160530/edd924e9/attachment.html>