Regression: importlib.metadata.PathDistribution.requires raises AttributeError, name/version raises TypeError

Bug report

Bug description:

Python 3.14.2

>>> from importlib import metadata
>>> d = metadata.PathDistribution.at('/tmp')
>>> d.requires
>>> d.requires is None
True

Python 3.15.0a3

>>> from importlib import metadata
>>> d = metadata.PathDistribution.at('/tmp')
>>> d.requires
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    d.requires
  File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 660, in requires
    reqs = self._read_dist_info_reqs() or self._read_egg_info_reqs()
           ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 664, in _read_dist_info_reqs
    return self.metadata.get_all('Requires-Dist')
           ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get_all'

I believe this is a regression from 9b38c66 where the metadata property changed the type from _meta.PackageMetadata to _meta.PackageMetadata | None but other properties (here the requires property) do not account for it being None.

This was discovered as a failure of tests of rpmlint in Fedora's continuous testing of Python pre-releases: https://bugzilla.redhat.com/show_bug.cgi?id=2424585

CPython versions tested on:

3.15

Operating systems tested on:

Linux

Linked PRs

Upstream commit is python/importlib_metadata@57f31d7 from python/importlib_metadata#519 -- unfortunately, neither the commit nor the PR provide rationale for this change.

Similarly, before:

>>> d = metadata.PathDistribution.at('/tmp')
>>> d.name
>>> d.version
>>>

After:

>>> from importlib import metadata
>>> d = metadata.PathDistribution.at('/tmp')
>>> d.name
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    d.name
  File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 542, in name
    return md_none(self.metadata)['Name']
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
TypeError: 'NoneType' object is not subscriptable
>>> d.version
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    d.version
  File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 552, in version
    return md_none(self.metadata)['Version']
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

Agreed the regression seems to stem from the change in PathDistribution.metadata to return None. It does correctly return None, but downstream properties like .name, .version, and .requires weren't updated to handle the NoneType return.

I’d be happy to patch this if it is indeed a regression.

@jaraco

cc @jaraco

What is the deal here? Do I need to report this to https://github.com/python/importlib_metadata/ ?

Note that, based on tox-dev/pipdeptree#530 I think that .metadata being None is a regression of its own.

Hi, I'd like to work on this regression fix. I can see the issue is in PathDistribution where requires, name, and version methods don't handle self.metadata being None. I'll add proper None checks to all three methods.

I am not quite sure this is a proper fix. Considering self.metadata being None is a breaking change, I think the best way forward is to revert it.

How can I move this forward?

@hugovk

@hugovk As the release manager of 3.15, could you please help me determine what the best way forward is here? This change seems to violate PEP 387 – Backwards Compatibility Policy.

@jaraco

I talked with @jaraco and he'll take a look at this towards the end of the week.

@hugovk

This change was an intentional one, and I apologize for it not being clearly traceable to the rationale.

I only had to go one level deeper from python/importlib_metadata#519 to python/importlib_metadata#493 to see the rationale.

Instead, I would expect dist.metadata to be None when no metadata file is present, and to return an empty PackageMetadata object when a metadata file is present but empty.

And one layer deeper python/importlib_metadata#489 (comment) describes where the Python 3.14 behavior missed expectations (and conflated the absence of metadata with a degenerate, empty metadata).

I am not quite sure this is a proper fix. Considering self.metadata being None is a breaking change, I think the best way forward is to revert it.

I was assuming, perhaps incorrectly, that there would be little if any reliance on reading Distribution.metadata from invalid sources, so this change while technically incompatible was also refining the behavior around previously-unsupported edge cases, adding fidelity where the previous behavior was undefined and incidental. As mentioned in the referenced comments, I'd have expected email.message_from_string(None) to have raised an Exception and not produced a degenerate result, so it was an accident (and a bug) that this edge case didn't fail.

Based on those assumptions, I was treating this change as a (technically incompatible, but acceptable) bugfix.

[From PEP 387, API compatibility includes: ] Given a set of arguments, the return value, side effects, and raised exceptions of a function. This does not preclude changes from reasonable bug fixes.

Seeing the examples above, I'm now more concerned about the uses resulting from Hyrum's law.

I did release this behavior early in order to gather feedback, and based on this feedback, it does deserve some reconsideration. I don't want to simply revert the behavior, as I'd like to understand what is the proper design moving forward and whether or not that change deserves a deprecation period.

Regarding the .metadata property, I do feel as if the None value better reflects the reality of the situation, and my instinct was that downstream consumers not handling None should crash (including cases that hit internal use as reported above). Or maybe better would be to throw an exception (MetadataNotFound) and avoid the None return type altogether. I do feel it's important to help consumers distinguish between a metadata folder with a missing METADATA file (but potentially containing other metadata) and one with an empty METADATA file.

Let's not revert this quite yet.

@hugovk Based on my explanation above and the fact that this use case was only viable due to an accident in the underlying APIs, do you want to retroactively support the behavior and demand a deprecation period for the change?

To everyone else, what should be the desired behavior when resolving "metadata" (i.e. the fields) for a folder that lacks the METADATA file? Exception, None, or something else (maybe a DegeneratePackageMetadata object that's distinct from actual PackageMetadata)? My instinct now is it should raise an Exception (and keep the API pure).

[3.15] gh-143387: Update docs to reflect the behavior and note the ch…

Thanks Miro.

Hugo, let me know if I should add the note in What's New, or if that's something someone else will do (in the past, that's generally been handled by someone other than me).

@jaraco

@jaraco Please add it to What's New.

Nowadays we prefer contributors to update it directly (when needed), and then we might do some editing later.

gh-143387: Add news blurb for importlib.metadata highlighting the cha…

[3.15] gh-143387: Add news blurb for importlib.metadata highlighting …

py-importlib-metadata: update to 9.0.0.

Bump the all-pip group in /tools with 18 updates (#8956)

FTR another one: Pylons/plaster#38

build(deps): bump importlib-metadata from 8.7.1 to 9.0.0 (#628)

Add missing METADATA to test data for Python 3.15 compatibility

Properly handle missing METADATA on Python 3.15+

chore(deps): bump importlib-metadata from 8.7.1 to 9.0.0 in /backend (#…

build(deps): bump importlib-metadata from 8.7.1 to 9.0.0 (#21)

Navigation Menu

Repository navigation

Regression: importlib.metadata.PathDistribution.requires raises AttributeError, name/version raises TypeError #143387

Bug report

Bug description:

Python 3.14.2

Python 3.15.0a3

CPython versions tested on:

Operating systems tested on:

Linked PRs

51 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Regression: importlib.metadata.PathDistribution.requires raises AttributeError, name/version raises TypeError #143387

Description

Bug report

Bug description:

Python 3.14.2

Python 3.15.0a3

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

hroncok commented on Jan 3, 2026

hroncok commented on Jan 3, 2026

a12k commented on Jan 3, 2026

tomasr8 commented on Jan 3, 2026

hroncok commented on Jan 5, 2026

arunkumargururaj07-star commented on Jan 7, 2026

hroncok commented on Jan 8, 2026

hroncok commented on Feb 9, 2026

hroncok commented on Mar 3, 2026

hugovk commented on Mar 4, 2026

jaraco commented on Mar 6, 2026

51 remaining items

jaraco commented on May 20, 2026

hugovk commented on May 20, 2026

hroncok commented on Jun 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions