On Mon, Apr 12, 2021 at 12:29 PM Thomas Grainger <tagr...@gmail.com> 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, <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)
>>
>> 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-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/VP4JWZTXYXGUFI76UR6AIKTSCUK3ZM53/
>> 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
_______________________________________________
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/BK5BABIZTXUGB66ZEQP23UYHFFP2YA3E/
Code of Conduct: http://python.org/psf/codeofconduct/
