Over the years, I've seen __version__ used very broadly but not *quite* in all packages. I've always known it was a convention, not a requirement. But it turns out it's not even a "official" convention.
But it really would be nice if there was a consistent way that I could count on to get the version of a package at run time.
Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!
In the status note, it says:
Further exploration of the concepts covered in this PEP has been deferred
for lack of a current champion interested in promoting the goals of the PEP
and collecting and incorporating feedback, and with sufficient available
time to do so effectively.
Well, I may be willing to be that champion, if a core dev is willing to sponsor, and I see some interest from this group.
And, well, after 13 years, we've seen __version__ be very broadly, though certainly not universally used.
Honestly, I haven't looked to see to what extent setuptools supports it, but will, of course, do so if folks think this is worth pursuing.
Or maybe this is a settled issue in setuptools, and we just need to change the status of the PEP.
For my part, I FAR prefer the version info to be embedded in the code of the package in a simple way, rather than hiding among the setuptools/egg/pip metadata, and requiring setuptools.pkg_resources to get a version at runtime.
I note that PEP8 uses __version__ as an example of a "module level dunder" -- but only suggests where it should be put, not how it be used :-)
Of course, there will be a need to update the PEP to match current practice (and setuptools and pip)
Or should this be brought up on The Distutils-SIG list?
Christopher Barker, PhD (Chris)
Python Language Consulting
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython