Thanks Paul,
Having a __version__ attribute is fairly common these days, but definitely not universal even now. So the PEP still has a place, IMO.
Indeed -- I really think it needs to be finalized one way or another.
But a lot has changed in the last 13 years. Python packaging is built very much on packages having versions these days, so the *distribution* version (as covered in https://packaging.python.org/specifications/core-metadata/) is essential.
And with importlib.metadata, that version is introspectable at runtime. But that's different from a *package* version as exposed via __version__.
If I decide to move forward on this, I'll need to get up to speed on all that, particularly the distinction between a "distribution" and a "package". My instinct, from years of experience, is that distinction is most important for large systems, but adds complication for smaller, simpler packages, so I do hope that we can come up with something that's simple for the simple cases. In a practical way, I know a lot of folks get confused when the name of a package is different than what you import, e.g. pip install beautifulsoup4
import bs4
I presume you would use "beautifulsoup4" as the dist_name with importlib.metadata ? (see-- I don't even know for sure, that's how much I need to catch up! ) And I suspect there's still some debate over whether
we need the two, so I wouldn't assume the PEP is self-evidently a good thing.
I'm sure -- but what I DO think is "self-evidently a good thing." is to not have a dangling differed PEP on this -- let's make a decision and move on! There's a bunch of straightforward updating that needs to be done indeed.
Also, you should look at https://packaging.python.org/guides/single-sourcing-package-version/. The whole question of how to derive the distribution version from the package version is quite complex, with a number of common solutions, and also a number of people who will argue that you *shouldn't* single-source, but should just copy the value into the two places. The section of the PEP that covers this needs rewriting, and possibly even omitting, as there is no "standard" answer.
I agree here -- I think what needs to be official is what is In an installed package/distribution -- not how it gets there. But I do think the standard approach should be easy to do, even without special tools. As another data point, flit *requires* that the package has a
__version__ attribute.
Ahh -- that is a helpful motivator.
FWIW, I'm personally ambivalent on the subject - having a __version__ feels like it's probably a good thing, but it's very rare that I actually care in practice as a package consumer, so as a package creator it feels a bit like boilerplate that I add "for the sake of it".
I am absolutely the opposite here -- as a consumer, I very much use __version__ frequently, and as a package creator, I avoid the fancy stuff and just put a __version__ in my packages :-) I'd suggest keeping the scope of the PEP fairly limited - opinions
vary in this area, and are held fairly strongly, so you'd stand more chance of getting something accepted if you keep things focused on the basics.
Agreed.
Or should this be brought up on The Distutils-SIG list?
(That's the packaging category on Discourse these days).
OK, OK, I guess I'll need to finally join that ;-)
Honestly, I don't really know. It *could* be a packaging interoperability standard, but the rules it includes about stdlib modules push it into core python territory.
indeed, and that's actually the point here. However, I suspect that the core devs will strongly rely on PyPA's thoughts on the matter.
I suspect the best thing to do would be to check with the SC on their view, and if they want to toss it in my direction, I'm happy to make the decision.
How does one "check with the SC"? A post to python-dev? Sorry, but I'd rather not be a sponsor for this, as I'm pretty busy
with other things at the moment. But I hope this helps.
It sure does, thanks. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython