[Python-ideas] Re: Revive: PEP 396 -- Module Version Numbers ?

On Mon, Apr 12, 2021 at 12:29 PM Thomas Grainger wrote:

I prefer to use importlib.metadata.version("dist-name")

For my part, I don't like that approach -- I really believe in KISS. That requires a pile of infrastructure to be in place -- compared to a simple attribute in a package. It just makes so much more sense (to me ;-) ) to have a simple way to ask a package what version it is, and to set the version when you make a package. I've been struggling with setuptools mingling build, install, and run time behavior for years (decades!) and i've never liked it. That being said, it's 13 years after that PEP 396 was written, and things have gotten better, including importlib.metadata being in the standard library now, though it does say: """ Note: This functionality is provisional and may deviate from the usual version semantics of the standard library. """ So -- 13 years later and we're still struggling. I don't know what it takes to get everything in place for importlib.metadata to work, so I'll go take a look. Anyway, my real goals are to get something "Official" standardized, and for that something to be: - Simple and easy to use, both for package authors and package users. - Doable with standard tools, ideally in the stdlib -- and particularly not requiring any non-stdlib tools at runtime (like the old pkg_resources). It seems that may have been solved by importlib, but let's not have it be provisional then! And the fact is, that PEP's been provisional for 13 years, and __version__ is widely, but certainly not universally, adopted. We really should get a pronouncement on this one way or another. Thanks, -CHB

On Mon, 12 Apr 2021, 19:51 Christopher Barker, wrote:

...

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!

https://www.python.org/dev/peps/pep-0396/

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?

-CHB

,-- Christopher Barker, PhD (Chris)

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VP4JWZ... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython