SQLAlchemy integration fails to parse version `2.0.5.post1`

[jamadden]

How do you use Sentry?

Self-hosted/on-premise

Version

1.16.0

Steps to Reproduce

Call sentry_sdk.init() with SQLAlchemy integration and install SQLAlchemy==2.0.5.post1.

Expected Result

Success.

Actual Result

  File "///src/.../__init__.py", line 150, in <module>
    sentry_sdk.init(
  File "///.tox/py/lib/python3.10/site-packages/sentry_sdk/hub.py", line 121, in _init
    client = Client(*args, **kwargs)  # type: ignore
  File "///.tox/py/lib/python3.10/site-packages/sentry_sdk/client.py", line 117, in __init__
    self._init_impl()
  File "///.tox/py/lib/python3.10/site-packages/sentry_sdk/client.py", line 151, in _init_impl
    self.integrations = setup_integrations(
  File "///.tox/py/lib/python3.10/site-packages/sentry_sdk/integrations/__init__.py", line 124, in setup_integrations
    type(integration).setup_once()
  File "///.tox/py/lib/python3.10/site-packages/sentry_sdk/integrations/sqlalchemy.py", line 37, in setup_once
    raise DidNotEnable(
sentry_sdk.integrations.DidNotEnable: Unparsable SQLAlchemy version: 2.0.5.post1

This is very similar to #1811, which was fixed in #1812 but that doesn't handle all the possible PEP440 variations, [N!]N(.N)*[{a|b|rc}N][.postN][.devN]

[razzeee]

We're seeing this with the cloud version too. Which isn't surprising I guess.

[RazerM]

The version parsing in the other integrations is equally brittle in relation to PEP 440. It's probably best to use the regular expression provided in the PEP and parse the release group:

VERSION_PATTERN = r"""
    v?
    (?:
        (?:(?P<epoch>[0-9]+)!)?                           # epoch
        (?P<release>[0-9]+(?:\.[0-9]+)*)                  # release segment
        (?P<pre>                                          # pre-release
            [-_\.]?
            (?P<pre_l>(a|b|c|rc|alpha|beta|pre|preview))
            [-_\.]?
            (?P<pre_n>[0-9]+)?
        )?
        (?P<post>                                         # post release
            (?:-(?P<post_n1>[0-9]+))
            |
            (?:
                [-_\.]?
                (?P<post_l>post|rev|r)
                [-_\.]?
                (?P<post_n2>[0-9]+)?
            )
        )?
        (?P<dev>                                          # dev release
            [-_\.]?
            (?P<dev_l>dev)
            [-_\.]?
            (?P<dev_n>[0-9]+)?
        )?
    )
    (?:\+(?P<local>[a-z0-9]+(?:[-_\.][a-z0-9]+)*))?       # local version
"""

_regex = re.compile(
    r"^\s*" + VERSION_PATTERN + r"\s*$",
    re.VERBOSE | re.IGNORECASE,
)

Alternatively packaging.version or parver would work (probably not worth adding a dependency here).

[sl0thentr0py]

I actually don't know historically why we have our own ad-hoc parsers in the first place. One reason might be the python2/python3 mess.

Using something standardized given it does not add unnecessary overhead makes total sense to me.

[erdnaxeli]

I wonder why sentry should crash on this case. Should not it just not enable the integration?

[hynek]

I extremely prefer a crash over a silently disabled error reporting.

[erdnaxeli]

I don't expect my monitoring tool to crash my app.

The thing is I don't setup sentry in my tests, so CI tells me everything is ok. Then I deploy my app, and boom, everything crashes. I have rolling upgrade setup so it don't distrup everything, but still some cronjob where broken.
So I would like either sentry to never crash, or to be able to test it in some way so it crashes in my CI before deploy.

[jace]

Folks, is there any ETA on getting this fixed? I have a pin on the SQLAlchemy version now that I'd like to remove.

[d0ugal]

You can upgrade to 2.0.6 and remove the pin