Waiting for Tryton community feedback https://discuss.tryton.org/t/sentry-sdk-integration/1925

Regarding the failed checks:

• the Python-3.5 fail is due to a str vs bytes issue
• the Python-3.4 fail is due to the trytond>5.0 package not being distributed for that version
• the Python-2.7 and the PyPy failures are rather unexpected because AFAIU they were out of the contributed dependency matrix

If the community agrees, I would settle for the easy solution: only supporting python>=3.6

@n1ngu it's ok to remove py3.4-trytond-5.0 from the matrix by having multiple lines (see django)

In my eyes there should be no reason to call init() from an integration. This is something we want to enforce for all stable integrations as doing otherwise requires us to replicate the API of init() somewhere else. If people use your logging handler to initialize the SDK, how do they configure before_send or any other option that takes more complex arguments than a DSN?

In my eyes there should be no reason to call init() from an integration. This is something we want to enforce for all stable integrations as doing otherwise requires us to replicate the API of init() somewhere else. If people use your logging handler to initialize the SDK, how do they configure before_send or any other option that takes more complex arguments than a DSN?

That's a good point. This handler should be understood not as a framework integration but as a mean to inject code in tools that won't allow it. Obviously, if the default sdk initialization does not suffice for a particular purpose, neither will this handler. If this is a concern and such a feature was not acceptable for the core sdk I will retire it from this PR so we can focus on the actual trytond wsgi integration above! (but I'll still vendor it in my deployments 😁)

Regarding complex init() options: The "ignored_loggers" feature is already beyond my initial will, it is present because I felt it was extremely straightforward. With a similar schema, other init() options could be exposed, but obviously its complexity grows as with a need for a fair amount of documentation.

That's why I'd settle for the "use this only if the default init() suffices you" as an out-of-the-box mechanism to power people to use Sentry with not easily-hackable tools, even if the Sentry setup is not fully customizable.

@untitaker Stated with different words: this handler could be shipped alongside the EventHandler and BreadcrumbHandler in the sentry_sdk.integrations.logging module. Not to power full Sentry customization but to ease a naive Sentry initialization in honor to your own documentation:

Usually, you don’t need this. You can use this together with default_integrations=False if you want to opt into what the Sentry Python SDK captures. However, correctly setting up logging is difficult. Also, an opt-in approach to capturing data will miss errors you may not think of on your own.
( https://docs.sentry.io/platforms/python/logging/#handler-classes )

The alternative for this kind of not easily-hackable tools is a tedious logging config setup with the EventHandler, and still with the problem of "where to state the DSN"

@n1ngu I would much rather separate the discussion of alternative initialization methods from getting this integration merged. The former is more controversial imo

@n1ngu could you open a pr against https://github.com/getsentry/sentry-docs?

Example PR: getsentry/sentry-docs#867

I tried to push this but failed bc the PR is not editable for me:

diff --git a/sentry_sdk/integrations/trytond.py b/sentry_sdk/integrations/trytond.py
index 152e879..c1a669a 100644
--- a/sentry_sdk/integrations/trytond.py
+++ b/sentry_sdk/integrations/trytond.py
@@ -4,10 +4,14 @@ import sentry_sdk.hub
 import sentry_sdk.utils
 import sentry_sdk.integrations
 import sentry_sdk.integrations.wsgi
+from sentry_sdk._types import MYPY
 
 from trytond.exceptions import TrytonException  # type: ignore
 from trytond.wsgi import app  # type: ignore
 
+if MYPY:
+    from typing import Any
+
 
 # TODO: trytond-worker, trytond-cron and trytond-admin intergations
 
@@ -25,12 +29,19 @@ class TrytondWSGIIntegration(sentry_sdk.integrations.Integration):
 
         def error_handler(e):  # type: (Exception) -> None
             hub = sentry_sdk.hub.Hub.current
+
             if hub.get_integration(TrytondWSGIIntegration) is None:
                 return
             elif isinstance(e, TrytonException):
                 return
             else:
-                (event, hint) = sentry_sdk.utils.event_from_exception(sys.exc_info())
+                # If an integration is there, a client has to be there.
+                client = hub.client  # type: Any
+                event, hint = sentry_sdk.utils.event_from_exception(
+                    sys.exc_info(),
+                    client_options=client.options,
+                    mechanism={"type": "trytond", "handled": False},
+                )
                 hub.capture_event(event, hint=hint)
 
         # Expected error handlers signature was changed

could you apply it manually?

fwiw this is blocked on the doc changes

My bad. I am aware the ball is in my court. I can only spend here some spare work hours, plus I've been on vacation. But hopefully I'll have the documentation sorted in the short term!

Gonna get this out and document later