Readme and API still exposes Distribution class about importlib_metadata

[jaraco]

In GitLab by @jaraco on Sep 17, 2018, 22:25

changed the description

[jaraco]

In GitLab by @warsaw on Sep 17, 2018, 22:44

Is there a reason why

from importlib_metadata import version
__version__ = version(__name__)

doesn't work in the general case? E.g. with this:

1 file changed, 2 insertions(+)
importlib_metadata/__init__.py | 2 ++

modified   importlib_metadata/__init__.py
@@ -73,3 +73,5 @@ def _install():                                     # pragma: nocover
 
 
 _install()
+
+__version__ = version(__name__)

I get this:

$ .tox/py37-nocov/bin/python -c "import importlib_metadata; print(importlib_metadata.__version__)"
0.5

Sorry, I forget what the point was about __dist_name__. Where did that come from again?

[jaraco]

In GitLab by @warsaw on Sep 17, 2018, 22:45

I mean, I see it's reference in name_for_module() but I don't remember why we added that.

[jaraco]

In GitLab by @jaraco on Sep 18, 2018, 12:29

It all comes down to - do we wish to resolve a Python module/package to a (e.g. pip installed) Distribution. The reason it works for importlib_metadata.__init__ is because the module's __name__ happens to match exactly the Distribution's name.

But this technique wouldn't work in these scenarios:

When the distribution name is different, such as with path.py (whose module __name__ is path), or with pkg_resources (whose distribution is setuptools), or with importlib_metadata._common.

There are other cases that may be problemmatic too, like with namespace packages, where jaraco/functools.py does happen to map to the jaraco.functools distribution, but jaraco maps to many distributions... and when many of these namespace packages are installed together, there are modules and packages inside jaraco that all map to different distributions.

It would be nice for all of these cases to be able to reliably resolve their distribution package without having to re-supply it as path.py does.

We did expose the distribution function, which if supplied a module will return its distribution, but from inside a module, it's not always straightforward to get a handle on the module object (there's no __self__ on a module).

The name_for_module() method attempts to take a handle to a module and resolve its distribution, first using the common heuristic that a module's __name__ will match it's distribution package's name (as it does with importlib_metadata and jaraco.functools (a module) and jaraco.classes (a package).

And the name_for_module also allows the value for any given module to be overridden, so a module like pkg_resources could supply a .__dist_name__ of "setuptools", thus allowing for:

import pkg_resources
__version__ = importlib_metadata.version(pkg_resources)

But where this still falls short is in the pkg_resources module itself. If it wishes to expose its own version, it can't readily resolve on itself:

# pkg_resources.py
import importlib_metadata
__dist_name__ = 'setuptools'
__version__ = importlib_metadata.version(__name__)

In this case, it will not work because the caller isn't passing the pkg_resources module nor the distribution name (the only two inputs currently honored for the distribution function). That's what Distribution.from_named_module was meant to solve and why there's no suitable replacement for this recommendation.

The way I see it, we have two options. We either eliminate the concept of resolving a module to its distribution altogether and don't encourage the use of __name__ when it just happens to match. Or we try to provide a mechanism for robustly resolving a module (both from within and externally) to its distribution package.

My instinct is to adopt the first tact, removing the functionality, and then revisit options for re-introducing it.

[jaraco]

In GitLab by @jaraco on Sep 18, 2018, 12:37

mentioned in commit df455f5

[jaraco]

In GitLab by @jaraco on Sep 19, 2018, 01:37

closed via commit df455f5

[jaraco]

In GitLab by @jaraco on Sep 19, 2018, 01:37

closed via merge request !20

[jaraco]

In GitLab by @warsaw on Sep 19, 2018, 06:05

Thanks for the detailed explanation. I agree with your conclusion. Let's revisit the functionality later.

[jaraco]

In GitLab by @jaraco on Sep 20, 2018, 03:09

mentioned in merge request !23