On Wed, 14 Apr 2021 at 13:28, Victor Stinner wrote:

There are two main use cases for versions:

* Display them to the user * Compare versions to check if one is newer, older or the same

I dislike using strings for comparison. You need to use packaging.version for that: https://packaging.pypa.io/en/latest/version.html

Agreed, programmatic use should really conform to PEP 440 versioning, as implemented in packaging.version, if it's to align with existing packaging standards (which currently focus on *project* versions rather than package versions, but the distinction is not something we should be making a big deal of).

Many C libraries provide the version as a number of as 3 numbers (major, minor, micro). In its C API, Python provides all of them:

* PY_VERSION_HEX: single number * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION, PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers * PY_VERSION: string

In my Python projects, I like to provide the version as a tuple which can be used directly for comparison: version_a <= version_b. Example:

VERSION = (2, 2, 1) __version__ = '.'.join(map(str, VERSION))

The tuple might contain strings like "beta" or "rc", as soon as comparison makes sense ;-) Sadly, such tuple is no standardized. Which part is the major version? How to format it as a string?

Good luck with trying to standardize that ;-)

Agreed. We should stick to PEP 440 format strings, and not try to dictate other formats like (named) tuples. But does the PEP want to cover programmatic use *at all*? It would be possible to define __version__ as "a human-readable string in PEP 440 format" and note that any use other than for display to a person is outside the scope of the PEP. That's closer in spirit to the 13-year old version we currently have, but it does miss an opportunity as we now do have a standard version class ("standard" in the sense of "a packaging standard", but not "in the stdlib"). Paul

I recently encountered this, which is very useful, but only for a human-readable perspective.

...

...

import vaex vaex.__version__ {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '0.11.1'}

On Wed, Apr 14, 2021 at 2:01 PM Barney Gale wrote:

...

In my Python projects, I like to provide the version as a tuple which can be used directly for comparison

To add to this, comparing tuples doesn't always work well for projects where multiple release lines are maintained simultaneously, e.g. user-facing changes introduced in minor/point releases across several major versions. People use version numbers in wildly different ways.

Barney

On Wed, 14 Apr 2021 at 13:26, Victor Stinner wrote:

...

...

So what do you'all think? After thirteen years, it would be nice to put

On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker wrote: this to bed.

There are two main use cases for versions:

* Display them to the user * Compare versions to check if one is newer, older or the same

I dislike using strings for comparison. You need to use packaging.version for that: https://packaging.pypa.io/en/latest/version.html

Many C libraries provide the version as a number of as 3 numbers (major, minor, micro). In its C API, Python provides all of them:

* PY_VERSION_HEX: single number * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION, PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers * PY_VERSION: string

In my Python projects, I like to provide the version as a tuple which can be used directly for comparison: version_a <= version_b. Example:

VERSION = (2, 2, 1) __version__ = '.'.join(map(str, VERSION))

The tuple might contain strings like "beta" or "rc", as soon as comparison makes sense ;-) Sadly, such tuple is no standardized. Which part is the major version? How to format it as a string?

Good luck with trying to standardize that ;-)

Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MBBYB5AW... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4XWIWIKD... Code of Conduct: http://python.org/psf/codeofconduct/

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

Agreed! I was trying to figure out why an API from Vaex 3.x was no longer working, and to my human eye, this quickly pointed me at the issue. However as a way to automatically check for versions, this is a mess. I have no idea what additional keys the next version might add or remove, for example. I'm not even sure if this is dynamically determined based on optional components being installed or not. Providing this kind of information *somehow* feels like a useful thing to do. But .__version__ is probably not the right way to do it. On Wed, Apr 14, 2021 at 5:08 PM Christopher Barker wrote:

On Wed, Apr 14, 2021 at 7:48 AM David Mertz wrote:

...

...

...

...

vaex.__version__ {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '0.11.1'}

Well, THAT is a great argument for some official standardization!

There is sometimes a need for that sort of thing, but I think it's best handled by either putting __version__ in each sub_package, or having a different attribute altogether.

-CHB

-- Christopher Barker, PhD (Chris)

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker wrote:

Another possible issue: using Version would require an extra import in many module initializations -- is that a performance issue that would matter?

I like having a `Version` object that is easily importable in the standard library. I think it should relatively polymorphic. I.e. it should accept a module or package as an argument, but also should accept a string or a tuple. Maybe other objects from which one could reasonably extract a version. In particular, I think initializing this object with a module object should at least look for a .__version__ attribute, and appropriately case either a string (that looks sufficiently version-like) or a tuple. I think that if it doesn't succeed, it should become some sort of "cannot determine" object that is neither less than nor greater than any other Version object. In particular, the Vaex example with a dictionary of versions of each component should probably just become this "cannot determine" value (but as an instance of Version). -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Apr 13, 2021, at 22:40, Christopher Barker wrote:

Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!

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

I’d forgotten that this PEP was in Deferred state. I think it should be rejected and I plan on making that change. importlib.metadata is a much better approach to programmatically determining package versions. https://docs.python.org/3/library/importlib.metadata.html#distribution-versi... -Barry

On Wed, 14 Apr 2021 at 18:04, Eric V. Smith wrote:

...

Anyway, the question now for me is whether this is worth any more of my time.

So: - Is there someone willing to sponsor? - Do folks generally think there's a chance of it being accepted without a huge debate and expansion of scope.

I think that before these can be answered, you need to decide why this needs to be standardized. I don't see any reason to standardize it unless there's some programmatic use for these version strings. If it's just the user poking around on the REPL, then I think the status quo is fine. I've read the PEP, and the User Stories section talks about user convenience, not programmatic access.

I also think the distribution version is more useful than any __version__ information in each module/package. I realize this information might not be available, depending on how the code was installed (say, just by copying some files into the right place).

Agreed. The original PEP was very limited, just proposing a string value for user convenience, with no programmatic interface. Doing anything more than that is opening up a whole load of complexity and compatibility (with packaging) that no-one has expressed any need for. The distribution version (exposed via importlib.metadata) is the correct thing to use for anything programmatic. Paul PS I see Barry plans on rejecting the PEP, which I think is probably the right decision, given the way this thread has developed.

On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:

If it's not basically equivalent to packaging.version.Version (and based on PEP 440) then we'll be creating a nightmare of confusion, because PEP 440 versions are fundamental to packaging.

Are you suggesting that users should have to install an external module to tell what version of packages they are using?! What's wrong with Version(module.__version__)? And if the __version__

attribute isn't a valid version, raise an exception? That's what packaging.version does, and it's worked fine for the packaging ecosystem. Is there a benefit that justifies being different here?

Doesn't that seem really, really painful to use in an interactive shell? This is honestly (a simplified version of) what I tried in trying to learn packaging.version.Version. It was not a good experience: % conda create -n test python=3.9 pandas [...] % conda activate test % python

...

...

import packaging ModuleNotFoundError: No module named 'packaging' ^D % pip install packaging [...] % python import packaging import panda, numpy, re, statistics packaging.version.Version(pandas) AttributeError: module 'packaging' has no attribute 'version' from packaging.version import Version Version(pandas) TypeError: expected string or bytes-like object Version(pandas.__version__) Version(statistics.__version__) AttributeError: module 'statistics' has no attribute '__version__' Version(re.__version__) import vaex Version(vaex.__version__) TypeError: expected string or bytes-like object

I cannot find a case where the more verbose spelling is ever nicer than just referencing `mod.__version__` directly for such exploration. Yes, I get that formal packaging has different needs. But here it just seems like a lot more work to get a lot less information back. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Wed, 14 Apr 2021 22:23:44 +0100 Paul Moore wrote:

On Wed, 14 Apr 2021 at 21:59, David Mertz wrote:

...

On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote:

...

If it's not basically equivalent to packaging.version.Version (and based on PEP 440) then we'll be creating a nightmare of confusion, because PEP 440 versions are fundamental to packaging.

Are you suggesting that users should have to install an external module to tell what version of packages they are using?!

No. To tell what version of a package they are using, a string is sufficient.

They only need a version object if they want to do additional processing (like comparing versions, or checking whether a version meets a constraint).

Given that the packaging ecosystem already has a canonical version object (provided by the packaging library), which has been used and tested extensively in many environments, inventing a different API seems at best ill-advised. Whether the stdlib needs a version object. rather than leaving that functionality to a 3rd party library, is the same question that comes up for *any* functionality that's proposed for the stdlib, and I have no particular opinion in this case.

Tangentially, until now projects could use distutils's LooseVersion if they wanted to compare version numbers reliably. With distutils being deprecated, they'll have to either depending on packaging (which is a large dependency just for comparison version numbers) or vendor packaging's Version class (which is doable but still some bothersome additional work). Regards Antoine.

Paul Moore wrote:

What's wrong with Version(module.__version__)? And if the __version__ attribute isn't a valid version, raise an exception?

I don't have a deep answer, but I do think __version__ should be specified (or at least mentioned) at https://docs.python.org/3/reference/datamodel.html At the moment, I can't even find a listing of possible __dunder__ attributes, though I'm almost sure I've seen one in the past. -jJ

On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett wrote:

I don't have a deep answer, but I do think __version__ should be specified (or at least mentioned) at https://docs.python.org/3/reference/datamodel.html

Given the intent to reject PEP 394, I can't imagine any good would come of that. Drop a __version__ in your modules if you find it valuable, but otherwise, there's nothing to do here. -Fred -- Fred L. Drake, Jr. <fred at fdrake.net> "There is nothing more uncommon than common sense." --Frank Lloyd Wright

On Wed, Apr 14, 2021 at 2:23 PM Paul Moore wrote:

...

...

because PEP 440 versions are fundamental to packaging.

Are you suggesting that users should have to install an external module to tell what version of packages they are using?!

No. To tell what version of a package they are using, a string is sufficient.

exactly -- if we do anything at all here, it should probably be at least. if you provide a __version__ attribute, it should be a PEP 440 compliant string. That would at least make the use __version__ a touch more consistent. The next, more controversial, step would be to suggest that people SHOULD provide a __version__string on all top-level packages. I would like that -- the current situation where many, but not all packages have __version__ is really annoying. They only need a version object if they want to do additional

processing (like comparing versions, or checking whether a version meets a constraint).

And indeed, we could add the ability for packaging.version.Version objects to be able to compare themselves with compatible strings -- I think that would be pretty handy. Given that the packaging ecosystem already has a canonical version

object (provided by the packaging library), which has been used and tested extensively in many environments, inventing a different API seems at best ill-advised.

absolutely.

Whether the stdlib needs a version object. rather than leaving that functionality to a 3rd party library, is the same question that comes up for *any* functionality that's proposed for the stdlib, and I have no particular opinion in this case.

I don't think it's the same as any functionality -- if we do want to better standardize package versioning in Python, and I think we should, then the Version object may become something useful to, and maybe even needed by, virtually every third party package. Which makes it a pretty prime candidate for the stdlib. Alternatively, the packaging package is pretty small, but if it grows, it might be good to split out the run-time vs build-time pieces. It's designed for programmatic use, not interactive use, yes. But

that's sort of my point, why do you want anything more than the bare string in the REPL? What are you planning on doing with it?

there is something in between the REPL and full on system development -- something simple for quickly scripts is nice too. But a simple standardised version string is fine for that. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Thu, 15 Apr 2021 11:37:28 +0200 Victor Stinner wrote:

Paul Bryan:

...

Seems like this is something that should make its way into stdlib?

In the last 10 years, the trend is more to remove anything related to packaging *outside* the stdlib :-) Since it's evolving way faster

What is "evolving way faster"? packaging.version implements PEP 440, which has been approved in 2014. Recent changes have been really minor: https://github.com/pypa/packaging/commits/main/packaging/version.py

On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker wrote:

Presumably that's why importlib.metadata exists in the stdlib.

...

...

import re, statistics, pandas, vaex, bs4 for mod in [re, statistics, pandas, vaex, bs4]: ... try: ... print(mod.__name__, end=" ") ... print(mod.__version__) ... except: ... print("__version__ not present") ... re 2.2.1 statistics __version__ not present

...

...

for mod in [re, statistics, pandas, vaex, bs4]: ... try: ... print(mod.__name__, version(mod.__name__)) ... except Exception as err: ... print(mod.__name__, repr(err)) ... re PackageNotFoundError('re') statistics PackageNotFoundError('statistics')

I was so hopeful about this, but in the end... not really. I have not used this capability before. Here are a few different situations I know of: pandas 1.2.4 vaex {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '0.11.1'} bs4 4.9.3 pandas 1.2.4 vaex 4.1.0 bs4 PackageNotFoundError('bs4') It seems like (somehow or another) importlib.metadata is doing something perhaps more useful for vaex. But it is doing distinctly worse for re, statistics, and bs4. Version is arguably useful from the package user side. As I believe Victor

mentioned, there are two uses for version information: display to the user -- for which version strings are fine, or programmatic comparison -- for which something like the Version object is very helpful. Do we only need to use version information programmatically when we are creating (or installing) packages? I don't think so -- I know I have code that (poorly) does version checking programmatically.

I think the key thing that Chris and I are pointing to is that there is a definite use for versions that is NOT for package maintainers/creators. Interactive use is definitely one such case, and eyeballing something, even if it is the oddball use that Vaex has, can help with figuring out an issue. But in actual code, I relatively often do something like this. Or rather, the below is what I would find really nice to be able to do. ver = robust_version(module) if ver >= (5, 2, 1): doit_modern_style() elif ver < (5, 2, 1): doit_old_style else: doit_unversioned_style() I'd like code like that to ALWAYS succeed. No exceptions raised. And it would *usually* use reasonable heuristics to figure out some sort of structured version info as well as is possible. I.e. probably look in several places and return some custom object that represents a "best effort." That object might be like NaN in being neither less than nor more than other things, in the fallback case. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Thu, 15 Apr 2021 09:38:41 -0700 Barry Warsaw wrote:

On Apr 14, 2021, at 23:11, Christopher Barker wrote:

...

You wrote the original PEP, so of course you can withdraw it (or reject it), but...

Are you sure? See this discussion, I don't think it's as simple as all that.

From a library maintainers point of view, I personally want to get away from using __version__ strings at all. They’re kind of a pain to remember to bump on every new release.

This is often handled using `setuptools_scm` or `versioneer` (see PyPI for each of these packages). Regards Antoine.

On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker wrote:

On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner wrote:

...

Paul Bryan:

...

Seems like this is something that should make its way into stdlib?

In the last 10 years, the trend is more to remove anything related to packaging *outside* the stdlib :-)

Well, maybe all of us don't think that's a good idea ;-)

As an active participant in the PyPA side of the packaging ecosystem and one of the maintainers of 'packaging', I am definitely NOT in favour of moving any of 'packaging' into the stdlib, nor breaking it up. We are taking distutils out of the stdlib for a reason. Backsliding on plans that have been in place for years is not something I would want to see happen as the motivations have not changed.

But anyway, I would say removing anything *related* to packaging outside the stdlib is a bad idea -- requiring an external tool to build a package is OK, but requireing an external use packages, not so much.

You can totally use a package already as things exist today and will in the future; you're just wanting a specific way to interpret a package's metadata which I don't view as the same thing.

Presumably that's why importlib.metadata exists in the stdlib.

It's there because of how tightly it binds to the import system; same goes for importlib.resources.

Version is arguably useful from the package user side. As I believe Victor mentioned, there are two uses for version information: display to the user -- for which version strings are fine, or programmatic comparison -- for which something like the Version object is very helpful. Do we only need to use version information programmatically when we are creating (or installing) packages? I don't think so -- I know I have code that (poorly) does version checking programmatically.

No one said that's the *only* use-case, but just because there's more than that does not mean we should move any packaging code into the stdlib to support a zero-install use-case. A key point I want to make here is the version metadata is in every project's .dist-info/METADATA file. That's what importlib.metadata knows how to read and hence why people have been suggesting to use it. The version information is fundamental to the wheel format and in fact you can't have a wheel without it. So asking every Python project to set a __version__ isn't going to change accessibility of version numbers when it comes to installed projects.

On Apr 15, 2021, at 09:54, Antoine Pitrou wrote:

On Thu, 15 Apr 2021 09:38:41 -0700 Barry Warsaw wrote:

...

On Apr 14, 2021, at 23:11, Christopher Barker wrote:

...

You wrote the original PEP, so of course you can withdraw it (or reject it), but...

Are you sure? See this discussion, I don't think it's as simple as all that.

From a library maintainers point of view, I personally want to get away from using __version__ strings at all. They’re kind of a pain to remember to bump on every new release.

This is often handled using `setuptools_scm` or `versioneer` (see PyPI for each of these packages).

Yep, exactly. (I knew about and had in mind setuptools_scm but I didn’t know about versioneer; thanks for that reference!) -Barry

On 4/15/2021 12:35 PM, David Mertz wrote:

re 2.2.1

re.__version__ was last modified 2001-10-07 by F. Lundh in bec95b9d8825b39cff46a8c645fa0eeb8409854e. What does '2.2.1' mean? Only Fredrik knows. The commit message says that he rewrote the pattern.sub and pattern.subn methods in C. That should have been user invisible except for speed. I believe that it is dead data left only for back compatibility and because of an inability to give a deprecation warning.

re PackageNotFoundError('re')

It seems like (somehow or another) importlib.metadata is doing something perhaps more useful for vaex.  But it is doing distinctly worse for re,

Is an effectively meaningless and misleading value better than none? IDLE once had a version last set, I believe, in 2.5 or 2.6, by K. Kaiser, with whatever meaning it had to him. I removed it in 3.6 (allowed by PEP 434 + RM decision). No one complained. The real version of any stdlib module is the Python version it is released with, plus and external app versions it is associated with (sqlite and ssl, for instance). It has been suggested, if not decided, that other versions should go. -- Terry Jan Reedy

On Thu, Apr 15, 2021 at 9:38 AM Barry Warsaw wrote:

From a library maintainers point of view, I personally want to get away from using __version__ strings at all. They’re kind of a pain to remember to bump on every new release.

PEP 396 has been dormant for a long time and I have no interest in

That’s a tooling issue, and I don’t think that Python itself should take any official stance on the tooling. But yes, anything that Python takes an official stance on should be able to be easily supported with not-too-complex tools.and I think a __version__ string fits this need. Personally, I use the __version__ string in my packages as the canonical source when I bold my packages. And there are fancier tools for more complex needs. pushing it forward any more. If someone else wants to take up the cause, I recommend creating a new PEP and referring back to 396. Fair enough -- I'm still gathering data to see if I should do just that. I am leaning toward at least SOME PEP about this -- having __version__ around as a semi-convention with no official recommendation as to if or how it should be used is kind of a mess. -CHB

On Thu, Apr 15, 2021 at 9:36 AM David Mertz wrote:

I was so hopeful about this, but in the end... not really. I have not used this capability before. Here are a few different situations I know of:

... ... re PackageNotFoundError('re') statistics PackageNotFoundError('statistics') pandas 1.2.4 vaex 4.1.0 bs4 PackageNotFoundError('bs4')

It seems like (somehow or another) importlib.metadata is doing something perhaps more useful for vaex. But it is doing distinctly worse for re, statistics, and bs4.

funny you should try bs4, which I also used as an example in another post. But what you have found is that there is a difference between a pacakge (which you can import) and a "distribution" which is something you install. importlib.metadata is looking for distributions. re and statistics are not distributions, but rather, built in pacakges (modules). bs4 is not a distributiuion, it is a package that is provided by the "beautifulsoup4" distribution. In [3]: importlib.metadata.version("beautifulsoup4") Out[3]: '4.9.3' Frankly, I'm still a bit confused about the distiction, but I do know for sure that a single distribution (maybe somethign that you can install via PyPi) can install more than one top-level package -- and certainly the packages/modules installed can have a different name than the distribution name. And if a distribution installs more than one package, they may have different version numbers. I'm not sure what to make of all this, though I'm leaning toward better suporting the distiction by asking for __version__ strings in top-level packages -- and maybe making importlib.metadata.version a bit smarter about looking for packages, and not just distributions. If you look at the docstring of metadata.version: """ In [2]: importlib.metadata.version? Signature: importlib.metadata.version(distribution_name) Docstring: Get the version string for the named package. :param distribution_name: The name of the distribution package to query. :return: The version string for the package as defined in the package's "Version" metadata key. File: ~/miniconda3/envs/py3/lib/python3.9/importlib/metadata.py Type: function """ It's a bit inconsistent with the use of the term "distribution" vs "package". That should get cleaned up if nothing else. Also, the Exception raised is "PackageNotFoundError" -- which should maybe be "DistributionNotFoundError"? Version is arguably useful from the package user side. As I believe Victor mentioned, there are two uses for version information: display to the user -- for which version strings are fine, or programmatic comparison -- for which something like the Version object is very helpful. Do we only need to use version information programmatically when we are creating (or installing) packages? I don't think so -- I know I have code that (poorly) does version checking programmatically.

Or rather, the below is what I would find really nice to be able to do.

ver = robust_version(module) if ver >= (5, 2, 1): doit_modern_style() elif ver < (5, 2, 1): doit_old_style else: doit_unversioned_style()

Exactly -- and I htink we are close, if pacakges(modules) had compliant __version__ strings, thenyou could do (with the Version object from packaging -- maybe why it should be in the stdlib) ver = Version(module.__version__) if ver >= Version("5.2.1"): doit_modern_style() elif ver < Version("5.2.1"): doit_old_style else: doit_unversioned_style() And if my PR is accepted (which looks unlikley) to allow camparison between Version objects and strings: ver = Version(module.__version__) if ver >= "5.2.1": doit_modern_style() elif ver < "5.2.1": doit_old_style else: doit_unversioned_style() A key distiction here from the importlib.metadata approach is the level of indirection -- I like being able to ask a module itself what version it is, rather than asking some other part of teh system to go look it up for me. So I could do: import numpy as np print("using np version:", np.__version) And this is pretty consitent with the rest of Python, where many objects (functions, classes, modules) have a __name__ attribute if things "know" their name, shouldn't they "know" their version as well? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Thu, 15 Apr 2021 at 21:03, Christopher Barker wrote:

I am leaning toward at least SOME PEP about this -- having __version__ around as a semi-convention with no official recommendation as to if or how it should be used is kind of a mess.

On the other hand, having a PEP that says you "may" have a version attribute, but mandates nothing, is pretty useless. People who conform to that convention don't need telling, people who don't have little reason to change, and people wanting to use the information still have to cater for it being missing, so they gain nothing. But a PEP that makes __version__ a requirement fails instantly, because there's too many packages in the wild that violate it. Welcome to the world of packaging PEPs :-)

I'm not sure what to make of all this, though I'm leaning toward better suporting the distiction by asking for __version__ strings in top-level packages -- and maybe making importlib.metadata.version a bit smarter about looking for packages, and not just distributions.

Personally, I'm leaning more and more towards the view that it's *distributions* that are versioned, and that's an established practice. Versioning packages as well (except in the very limited sense that package X installed by distribution Y can expose Y's version via its API) only adds confusion and makes the situation less, not more, useful for users. So I'm now -1 on any PEP to try to formalise the use of __version__. If people want to discuss the use of a __version__ attribute, they should consider contributing to the discussions on versions in https://packaging.python.org/guides/ (where the necessary context is already present). Paul

On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou wrote:

...

On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker wrote:

...

On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner wrote:

...

Paul Bryan:

...

Seems like this is something that should make its way into stdlib?

In the last 10 years, the trend is more to remove anything related to packaging *outside* the stdlib :-)

Well, maybe all of us don't think that's a good idea ;-)

As an active participant in the PyPA side of the packaging ecosystem and one of the maintainers of 'packaging', I am definitely NOT in favour of moving any of 'packaging' into the stdlib, nor breaking it up. We are taking distutils out of the stdlib for a reason. Backsliding on plans

On Thu, 15 Apr 2021 10:28:53 -0700 Brett Cannon wrote: that

...

have been in place for years is not something I would want to see happen as the motivations have not changed.

This seems gratuitously dogmatic. Version numbers are a simple feature that is stably encoded in PEP 440. It's purely computational, does not involve reading or saving any persistent state in the filesystem, making any network access, etc. Why wouldn't it have its place in the stdlib?

Technically PyPA specs might start as PEPs but their official home is packaging.python.org and updates can occur there outside of the PEP process. In the case of version specifiers ( https://packaging.python.org/specifications/version-specifiers/), they point back to the original PEP, but that is not universally true nor guaranteed to hold in the future. In other words I personally don't view the fact that it's a PEP as a reason to have it in the stdlib (else pretty much every single packaging PEP is missing). We also have other things standardized in PEPs and not covered in the stdlib, e.g. @ as an operator. So I don't think version comparison occurs often enough to be in the stdlib, and the fact that an external project exists which isn't interested in being put in the stdlib suggests to me it isn't worth doing. But that's a separate topic to discuss at the language summit. :)

...

...

But anyway, I would say removing anything *related* to packaging outside the stdlib is a bad idea -- requiring an external tool to build a package is OK, but requireing an external use packages, not so much.

You can totally use a package already as things exist today and will in the future; you're just wanting a specific way to interpret a package's metadata which I don't view as the same thing.

That specific way is a Python standard (PEP 440). Having the functionality in the stdlib would encourage people to use it. Not having it in the stdlib encourages people to use adhoc version parsing, or worse, naive string comparison.

I don't know if I draw the same line since the packaging community is relying on 'packaging' without issue for this exact thing.

...

So asking every Python project to set a __version__ isn't going to change accessibility of version numbers when it comes to installed projects.

That doesn't have much to do with the suggestion of shipping a Version class in the stdlib, though. Many projects already provide a __version__, and that field is often inspected programmatically in dependent packages (to work around behaviour changes, for example).

But this thread is about standardizing on __version__ which then led to wanting to bring in some Version object into the stdlib to make that more useful. So to me they are tied together, else a separate thread should probably be started if a new module *just *for version parsing support is desired.

Hi, sorry for being late to the party, but I may not be the only one wondering… Le 14/04/2021 à 20:56, Barry Warsaw a écrit :

I’d forgotten that this PEP was in Deferred state. I think it should be rejected and I plan on making that change. importlib.metadata is a much better approach to programmatically determining package versions.

https://docs.python.org/3/library/importlib.metadata.html#distribution-versi...

This is indeed the correct approach, thanks for letting me learn this. However, I unsuccessfully searched for the canonical way to look up the distribution name based on either a module name or an imported module object. Is there one? Looks like it could be computed based on information in "*.egg-info/installed-files.txt", but it's far from trivial. Is "installed-files.txt" even guaranteed to exist for all distributions? Cheers, Baptiste

On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon wrote:

On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello < devel2021@baptiste-carvello.net> wrote:

...

Hi,

sorry for being late to the party, but I may not be the only one wondering…

Le 14/04/2021 à 20:56, Barry Warsaw a écrit :

...

I’d forgotten that this PEP was in Deferred state. I think it should

be rejected and I plan on making that change. importlib.metadata is a much better approach to programmatically determining package versions.

...

https://docs.python.org/3/library/importlib.metadata.html#distribution-versi...

This is indeed the correct approach, thanks for letting me learn this.

However, I unsuccessfully searched for the canonical way to look up the distribution name based on either a module name or an imported module object. Is there one?

If you mean how to tie a module back to its name on PyPI, you should be able to look up the "Name" in the project's metadata: https://docs.python.org/3/library/importlib.metadata.html#distribution-metad... .

The missing bit here, for me, is how do you map a module back to it's project (distribution)? For example: ```

...

...

import bs4 bs4.__version__ '4.9.1' importlib.metadata.metadata('bs4') PackageNotFoundError: bs4

This is because the distribution calls itself 'beautifulsoup4' instead.

The same goes for another package: `umap`, for which the distribution is
called `umap-learn`


This is the best I could come up with from reading the docs:

    import bs4  #<- This is the module we want the version of

    import importlib
    import sys
    from itertools import chain
    from pathlib import Path

    loaders = sys.meta_path

    target_path = Path(bs4.__file__)

    distros = list(chain(*(finder.find_distributions() for finder in
loaders if hasattr(finder, 'find_distributions'))))
    distros_files = chain(*(f for f in (d.files for d in distros)))
    distro_files = [(d, d.locate_file(f)) for d in distros if d.files for f
in d.files]
    matching = [d for d, f in distro_files if f == target_path]

    for match in matching:
        print("Found Version:", match.version)

Steve

On Tue, 27 Apr 2021 at 18:01, Brett Cannon wrote:

Unfortunately I thought importlib.metadata would have used the module name instead of the metadata details, but in hindsight am guessing that the .dist-info is what it's using to do the lookup and that's based on the package name instead of the project name.

This is a long-standing issue with projects that use project names which differ from their module name, but there's no good way without checking what files a project installed (which is what you're doing below).

That's correct. There is no link from a given import name back to the PyPI project name. And the metadata for installed packages (defined here: https://packaging.python.org/specifications/recording-installed-packages/) is keyed on the PyPI project name, as the OP noted ("beautifulsoup4" rather than "bs4", "setuptools" rather than "pkg_resources", etc).

...

This is the best I could come up with from reading the docs:

import bs4 #<- This is the module we want the version of

import importlib import sys from itertools import chain from pathlib import Path

loaders = sys.meta_path

target_path = Path(bs4.__file__)

distros = list(chain(*(finder.find_distributions() for finder in loaders if hasattr(finder, 'find_distributions')))) distros_files = chain(*(f for f in (d.files for d in distros))) distro_files = [(d, d.locate_file(f)) for d in distros if d.files for f in d.files] matching = [d for d, f in distro_files if f == target_path]

for match in matching: print("Found Version:", match.version)

The following is a bit simpler. The file.locate() method of a distribution is undocumented - but I tried to use resolve() on the path object I got from dist.files, and it appears not to be implemented (at least in Python 3.9) - PackagePath objects are a subclass of *Pure* Path objects, not concrete paths :-( TBH, I suspect the fact that it's undocumented is an oversight, it's clearly deliberately added. import importlib.metadata from pathlib import Path import pkg_resources target = Path(pkg_resources.__file__) for dist in importlib.metadata.distributions(): for file in dist.files: path = file.locate() if path == target: print(f"{dist.metadata['name']}: {dist.version}") break To be honest, if anyone were interested in making a PEP from any of this, having Python modules contain a __distribution_name__ attribute that links the module back to the PyPI distribution, would probably be more useful than standardising __version__. But I'm not sufficiently interested to do anything more than mention that as a possibility. Paul