On Mon, 12 Apr 2021 at 19:52, Christopher Barker <python...@gmail.com> 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)
Having a __version__ attribute is fairly common these days, but definitely not universal even now. So the PEP still has a place, IMO. 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__. 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. There's a bunch of straightforward updating that needs to be done (all of the PEPs that this one references have since been superseded, and in the case off package metadata, it's no longer standardised via a PEP but at https://packaging.python.org/specifications/core-metadata/). 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. As another data point, flit *requires* that the package has a __version__ attribute. 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'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. > Or should this be brought up on The Distutils-SIG list? (That's the packaging category on Discourse these days). 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. And packaging standards tend to be more about distribution-level metadata than package-level. 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. 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. Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/W6RDBPPM77QQRNJ3YI3MFTXSMSCRD6PW/ Code of Conduct: http://python.org/psf/codeofconduct/
