Skip to content

importlib_metadata.metadata("") start raising ValueError since 4.12.0 #395

Description

@Czaki

Hello,

In napari we use the following code to check the metadata of the package used as a launcher of the application:

app_module = sys.modules['__main__'].__package__
try:
    metadata = importlib_metadata.metadata(app_module)
except importlib_metadata.PackageNotFoundError:
    ...

as importlib_metadata is replacement for importlib.metadata then there is inconsitece as for python 3.8-3.10 the following code executes correctly:

In [2]: importlib.metadata.metadata(None)
Out[2]: <email.message.Message at 0x7fdb7c5ff5e0>

but

importlib_metadata.metadata(None)

ends with error from #391

I found this issue, but as I understand that solution will impact python 3.11 or python 3.12

python/cpython#93259

it is possible to restore old behaviour for old version of python to not break existing code? I understand that new version of libraries should be fixed, but such updates should not break existing code.

Activity

jaraco commented on Jul 29, 2022

@jaraco
Member

The fact that metadata("") or metadata(None) did not raise an error was a bug and probably didn't do what you intended it to do. It was unexpected that users would rely on this behavior, which is why it was released as a minor release and not a major (breaking) release. I'd suggest to pin to importlib_metadata<4.12 in affected environments to work around the issue.

Because it was a backward-incompatible change introduced in a point release, it's conceivable that we should roll back the change, and then re-apply the change in a major release (5.0), but I suspect that wouldn't help your situation. Would that help any more than for you to pin to <4.12?

it is possible to restore old behaviour for old version of python to not break existing code?

importlib_metadata attempts to provide a uniform implementation across all versions of Python and does not wish to provide divergent implementations based on Python versions.

Czaki commented on Jul 29, 2022

@Czaki
Author

The core problem for us is that it affects the already released version that is available on pypi. New releases are working, but in science, it sometimes needs to install old releases for reproducibility. But if you think that such change is wrong we will try to put proper information in documentation.

jaraco commented on Jul 29, 2022

@jaraco
Member

New releases are working, but in science, it sometimes needs to install old releases for reproducibility.

I understand reproducibility is important. In that case, the best thing to do to maintain reproducibility and compatibility is not to update importlib_resources (keep the pin to <4.12).

But if you think that such change is wrong we will try to put proper information in documentation.

Indeed, I don't see a way short of restoring the prior behavior and re-introducing the bug. I'm not sure what documentation you speak of, but yes, I'd recommend to link to this issue to inform any users affected. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    invalidThis doesn't seem right

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions