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