On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou
On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker
wrote: On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner
wrote: Paul Bryan:
Seems like this is something that should make its way into stdlib?
In the last 10 years, the trend is more to remove anything related to packaging *outside* the stdlib :-)
Well, maybe all of us don't think that's a good idea ;-)
As an active participant in the PyPA side of the packaging ecosystem and one of the maintainers of 'packaging', I am definitely NOT in favour of moving any of 'packaging' into the stdlib, nor breaking it up. We are taking distutils out of the stdlib for a reason. Backsliding on plans
On Thu, 15 Apr 2021 10:28:53 -0700 Brett Cannon
wrote: that have been in place for years is not something I would want to see happen as the motivations have not changed.
This seems gratuitously dogmatic. Version numbers are a simple feature that is stably encoded in PEP 440. It's purely computational, does not involve reading or saving any persistent state in the filesystem, making any network access, etc. Why wouldn't it have its place in the stdlib?
Technically PyPA specs might start as PEPs but their official home is packaging.python.org and updates can occur there outside of the PEP process. In the case of version specifiers ( https://packaging.python.org/specifications/version-specifiers/), they point back to the original PEP, but that is not universally true nor guaranteed to hold in the future. In other words I personally don't view the fact that it's a PEP as a reason to have it in the stdlib (else pretty much every single packaging PEP is missing). We also have other things standardized in PEPs and not covered in the stdlib, e.g. @ as an operator. So I don't think version comparison occurs often enough to be in the stdlib, and the fact that an external project exists which isn't interested in being put in the stdlib suggests to me it isn't worth doing. But that's a separate topic to discuss at the language summit. :)
But anyway, I would say removing anything *related* to packaging outside the stdlib is a bad idea -- requiring an external tool to build a package is OK, but requireing an external use packages, not so much.
You can totally use a package already as things exist today and will in the future; you're just wanting a specific way to interpret a package's metadata which I don't view as the same thing.
That specific way is a Python standard (PEP 440). Having the functionality in the stdlib would encourage people to use it. Not having it in the stdlib encourages people to use adhoc version parsing, or worse, naive string comparison.
I don't know if I draw the same line since the packaging community is relying on 'packaging' without issue for this exact thing.
So asking every Python project to set a __version__ isn't going to change accessibility of version numbers when it comes to installed projects.
That doesn't have much to do with the suggestion of shipping a Version class in the stdlib, though. Many projects already provide a __version__, and that field is often inspected programmatically in dependent packages (to work around behaviour changes, for example).
But this thread is about standardizing on __version__ which then led to wanting to bring in some Version object into the stdlib to make that more useful. So to me they are tied together, else a separate thread should probably be started if a new module *just *for version parsing support is desired.