`sentry_sdk.init()` slowed by module-level `package_version("mcp")` scanning all installed distributions (2.64.0)

[tejas7777]

How do you use Sentry?

Sentry Saas (sentry.io)

Version

2.64.0

Steps to Reproduce

In any environment with a few hundred installed packages and mcp not installed:

import time
from sentry_sdk.integrations import DidNotEnable

t = time.perf_counter()
try:
    import sentry_sdk.integrations.mcp
except DidNotEnable:
    pass
print(f'{time.perf_counter() - t:.3f}s')

With ~200 installed distributions: 0.202s on 2.64.0 vs 0.052s on 2.63.0. The cost scales with the number of installed distributions.

sentry_sdk.init() imports this module through auto-enabling integrations, so every init() pays this even when mcp is not installed. In a process where all other imports are already warm (e.g. a forked worker), init() goes from ~0.04s to ~0.28s.

Expected Result

When mcp is not installed, the MCP integration raises DidNotEnable without doing any expensive work, as in 2.63.0.

Actual Result

#6583 added a module-level call at the top of sentry_sdk/integrations/mcp.py, above the try/except ImportError guard:

MCP_PACKAGE_VERSION = package_version("mcp")

package_version() -> _get_installed_modules() parses the metadata of every installed distribution. Profiling init() attributes nearly all of the added time to this line.

This mainly hurts short-lived processes that call init() per process (test suites forking workers, CLIs, cron jobs) - our CI worker-boot timing assertions started failing on the 2.63.0 -> 2.64.0 bump.

Suggested fix: move the package_version("mcp") call below the import mcp guard (or compute it lazily in setup_once()), so environments without mcp skip the scan.

[linear-code]

PY-2599

[alexander-alderman-webb]

Thanks @tejas7777 I'll address