On 28 May 2016 3:36 am, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 28 May 2016 at 05:38, Ethan Furman <ethan@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Nick Coghlan