importlib-metadata breaks code

@agronholm

          Was there a need to unconditionally use `importlib-metadata`, even on Python >= 3.10? This change broke my application framework (Asphalt) because it does `isinstance(value, EntryPoint)`, checking against `importlib.metadata.EntryPoint`, but after `importlib_metadata` is imported, iterating entry points (even through the stdlib facilities) yields `EntryPoint` instances from that third party library, which are NOT compatible with the stdlib ones!

EDIT: I see that importlib.metadata.EntryPoint is not directly documented in the API docs.

Originally posted by @agronholm in #3167 (comment)

Given that importlib.metadata is no longer provisional in Python 3.10, its API is stable, so the workaround should only be used for Python 3.9 and earlier.

Pinning to 1.16.0 temporarily fixed the issue for us in Python 3.11.

@agronholm

Given that importlib.metadata is no longer provisional in Python 3.10, its API is stable, so the workaround should only be used for Python 3.9 and earlier.

That makes sense to me 👍

Just to make sure I understand @agronholm, your original description of the issue does not sound like an issue with OpenTelemetry's usage of the library. It kind of sounds like an issue in either Asphalt (you mentioned EntryPoint is not documented looks fixed in this commit) in combination with some weird side effects between importlib.metadata and importlib-metadata.

Is that right?

@agronholm

Just to make sure I understand @agronholm, your original description of the issue does not sound like an issue with OpenTelemetry's usage of the library. It kind of sounds like an issue in either Asphalt (you mentioned EntryPoint is not documented looks fixed in this commit) in combination with some weird side effects between importlib.metadata and importlib-metadata.

Yeah, it was only after upgrading the opentelemetry libs to 0.38b0 that I encountered this issue. Asphalt itself only uses the backport on Python 3.9 and earlier. It's not needed on 3.10 or later, and is just extra baggage there. I don't know if anybody is doing isinstance() with EntryPoint elsewhere, but if they do, they'll encounter the same issue.

At any rate, the latest Asphalt no longer uses the EntryPoint class for comparisons so it's not an issue for me any longer.

@mvilanova

@mvilanova did you encounter this outside of Asphalt? If not I think we should close this bug and open a separate one to make it conditional import for python<3.10

fix reliance on 6.0.X series importlib-metadata

Use imporlib.metadata on python >=3.10

Hi folks! Any update on this? We're still stuck with pinning to 1.16.0 and would love to un-pin.

@jsjeannotte

@jsjeannotte

There was a pr that was closed so this issue still exists. @ocelotl for visibility. Seems like import-metadata still causing headaches :D

@jsjeannotte

@jsjeannotte

Can you elaborate if you are experiencing breaking changes? Can you try upgrading to the latest opentelemetry to see if importlib-metadata is causing you issues?

I'm reaching out internally for the details, but a colleague using one of my python library reported this issue again when I unpinned opentelemetry-api on Tuesday (and picked up 1.20.0). They're running on Python 3.11. This is the stack trace they sent me:

  File "/apps/sirtdispatch/src/dispatch/extensions.py", line 3, in <module>
    import nflxlog
  File "/apps/sirtdispatch/lib/python3.11/site-packages/nflxlog/__init__.py", line 14, in <module>
    from opentelemetry import trace
  File "/apps/sirtdispatch/lib/python3.11/site-packages/opentelemetry/trace/__init__.py", line 87, in <module>
    from opentelemetry import context as context_api
  File "/apps/sirtdispatch/lib/python3.11/site-packages/opentelemetry/context/__init__.py", line 25, in <module>
    from opentelemetry.util._importlib_metadata import entry_points
  File "/apps/sirtdispatch/lib/python3.11/site-packages/opentelemetry/util/_importlib_metadata.py", line 17, in <module>
    from importlib_metadata import (  # type: ignore
ImportError: cannot import name 'EntryPoints' from 'importlib_metadata' (/apps/sirtdispatch/lib/python3.11/site-packages/importlib_metadata/__init__.py)

My guess is another dependency in their project is pinning to an incompatible version of importlib_metadata? Anyhow, I'm wondering if proactively fixing opentelemetry-api by using importlib.metadata for Python > 3.7 and conditionally including importlib_metadata for Python 3.7 would remove the issue completely.

The use of importlib-metadata, and the capped pin to < 8.8.0 are still causing pain. Why is the version capped? Can we talk more about removing the use of the library?

@xrmx

@xrmx could this decision be revisited now? Since the SIG meeting, both Python 3.8 and 3.9 reached their EOL and their support was removed from the codebase (see PR #5076)

@nedbat

The use of importlib-metadata, and the capped pin to < 8.8.0 are still causing pain. Why is the version capped? Can we talk more about removing the use of the library?

We have discussed this on the last SIG meeting, the fear is backward incompatible changes in the stdlib (something already changed in 3.13 but should not affect us).
And yes we should bump the version there, @nedbat any chance you can open a PR with the bump (<9.1), also in opentelemetry-api/test-requirements.txt and an entry in the changelog please?

@nedbat

And yes we should bump the version there, @nedbat any chance you can open a PR with the bump (<9.1), also in opentelemetry-api/test-requirements.txt and an entry in the changelog please?

How are you choosing that new upper bound? What is special about 9.1?

And yes we should bump the version there, @nedbat any chance you can open a PR with the bump (<9.1), also in opentelemetry-api/test-requirements.txt and an entry in the changelog please?

How are you choosing that new upper bound? What is special about 9.1?

I guess they have historically pinned to minor versions, so in my PR I just bumped to the latest minor version.

So long as the minor version keeps being bumped with new releases it's not a problem and has the benefit of ensuring CI is run against new versions before users test out that combination in the wild.

That said, it's more usual to pin to a major version - pinning to a minor version is quite conservative.

If you look at the table here https://github.com/python/importlib_metadata#compatibility they haven't been strongly sticking to semver.

Do you have high confidence that the next major version will be fine?

So what is the problem with a conditional import?

if sys.version_info >= (3, 10):
    from importlib.metadata import (
        Distribution,
        EntryPoint,
        EntryPoints,
        PackageNotFoundError,
        distributions,
        entry_points,
        requires,
        version,
    )
else:
    from importlib_metadata import (
        Distribution,
        EntryPoint,
        EntryPoints,
        PackageNotFoundError,
        distributions,
        entry_points,
        requires,
        version,
    )

This is what all other projects, as I can see, do.

Does this actually work? I haven't tested since we dropped 3.9, but it looks like there are still some differences across minor versions in the return value of entry_points()

If 3.9 support has been dropped, why is importlib_metadata involved at all?

There are still some differences in the return type of entry_points() in 3.12 and 3.13. It's possible it works fine for our use cases since we don't depend on the tuple like interface, in which case I'm open to removing it.

Quoting from the importlib.metadata docs:

Changed in version 3.12: The “selectable” entry points were introduced in importlib_metadata 3.6 and Python 3.10. Prior to those changes, entry_points accepted no parameters and always returned a dictionary of entry points, keyed by group. With importlib_metadata 5.0 and Python 3.12, entry_points always returns an EntryPoints object. See backports.entry_points_selectable for compatibility options.

When I looked into removing the backport a few weeks ago, I thought there was a chance we'd still need the backport for 3.10 and 3.11, but after reading the section above, it's clear we don't (the only difference is that in 3.10/3.11 the return type of entry_points() is dict-like).

I'm in favor of removing the backport entirely. We just need to be cautious when/if we decide to make use of other parts of the importlib.metadata API, but in my opinion this is unlikely.

One more point to add is that while there technically are breaking changes to entry_points() between 3.12 and 3.13, we don't make use of this behavior:

Changed in version 3.13: EntryPoint objects no longer present a tuple-like interface (getitem()).

I took a stab at it in #5203. Turns out that we still need some shim layer because, as the python docs say, the behavior is different if you use selectable entry points or not and we use both.

~~It looks like using distributions() directly we can side step this and provide a consistent API.~~

fix(deps): switch importlib_metadata import to stdlib importlib.metadata

Nightly dependency update: OpenTelemetry 1.42.1/0.63b1 (#762)

Navigation Menu

Repository navigation

`importlib-metadata` breaks code #3234

12 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

importlib-metadata breaks code #3234

Description

Activity

agronholm commented on Mar 23, 2023

mvilanova commented on Mar 23, 2023

aabmass commented on Mar 23, 2023

agronholm commented on Mar 23, 2023

agronholm commented on Mar 23, 2023

aabmass commented on Mar 23, 2023

jsjeannotte commented on Oct 10, 2023

lzchen commented on Oct 11, 2023

lzchen commented on Oct 12, 2023

jsjeannotte commented on Oct 14, 2023

12 remaining items

nedbat commented on Apr 27, 2026

sk- commented on May 3, 2026

xrmx commented on May 4, 2026

nedbat commented on May 4, 2026

dhirschfeld commented on May 8, 2026

aabmass commented on May 11, 2026

aabmass commented on May 11, 2026

agronholm commented on May 11, 2026

aabmass commented on May 11, 2026

herin049 commented on May 12, 2026

herin049 commented on May 12, 2026

aabmass commented on May 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

`importlib-metadata` breaks code #3234