Scoped sentry_sdk.init for per-package logging

It looks like sentry_sdk.init integrations are generally attached in a global way. For example, the LoggingIntegration wraps logging.Logger.callHandlers [1], and ExcepthookIntegration wraps sys.excepthook [2].

Let’s say you have multiple Sentry projects (Project A, Project B, Project C) that each correspond to one Python package (Package A, Package B, Package C). All packages could be used independently, so it makes sense to instrument all of them individually with sentry_sdk.init. However, if Package C depends on Package A and B, then it would seem that Project C will receive all error notifications even though some of the errors might actually be caused by Packages A and B. Ideally, I’d like to be able to do a scoped sentry_sdk.init on the three packages so that errors from different packages are routed to their corresponding Sentry project, regardless of their interdependencies.

Is such a use case supported, or are there any plans to support this use case in the future?

Potentially relevant issue: https://github.com/getsentry/sentry-python/issues/198.

[1] https://github.com/getsentry/sentry-python/blob/master/sentry_sdk/integrations/logging.py#L72 [2] https://github.com/getsentry/sentry-python/blob/master/sentry_sdk/integrations/excepthook.py#L46

[untitaker]

Instead of writing sentry_sdk.init(), write:

_library_client = sentry_sdk.Hub(sentry_sdk.Client(...))

Then you can wrap each codeblock that should go to that different client with:

with _library_client:
    ...

All the integrations work too, just provide them as kwargs to Client as you would do with init. Of course they would still monkeypatch under the hood, but they will always try to use Hub.current which will point to _library_client to figure out which integrations are actually supposed to run and where to send events.

This can also be used to disable the SDK on a per-codeblock level like this:

with sentry_sdk.Hub():
   ...

[untitaker]

That seems like a fine approach, and I think it’s as close to a generic impl as you can get. I still think that this makes too many assumptions about how the library API works (assumptions which might be common sense), so I think libraries should vendor this logic and adapt it to their own usecases. For example this somewhat falls apart with underscore-prefixed types which would normally not constitute an API boundary, or when passing callbacks into a library method/function, or when a library method/function returns another function.

A bug that I would fix is that your wrapper for AsyncFunctionDef should likely await for the return value within the try-except. Otherwise you are only catching exceptions for the timeframe where the future/task/promise is created, not when it is being executed.