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
_______________________________________________ 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/7HYTS74GTZBW5473MUGDL2SIK37GESVN/ Code of Conduct: http://python.org/psf/codeofconduct/
