From 2d9b89fe429d2b1d1c448f657629bbdb6ba1ff77 Mon Sep 17 00:00:00 2001 From: Markus Unterwaditzer Date: Sun, 24 Nov 2019 19:32:49 +0100 Subject: [PATCH 1/2] fix: Make package metadata consistent in setup.py --- CONTRIBUTING.md | 6 ++++++ setup.py | 12 +++++++++++- tox.ini | 8 ++++---- 3 files changed, 21 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 84440201d8..9070d725d9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -44,6 +44,12 @@ The usual release process goes like this: * Allow the user to disable the integration by changing the client. Check `Hub.current.get_integration(MyIntegration)` from within your signal handlers to see if your integration is still active before you do anything impactful (such as sending an event). +3. Update package metadata. + + * We use `extras_require` in `setup.py` to communicate minimum version requirements for integrations. People can use this in combination with tools like Poetry or Pipenv to detect conflicts between our supported versions and their used versions programmatically. + + Do not set upper-bounds on version requirements as people are often faster in adopting new versions of a web framework than we are in adding them to the test matrix or our package metadata. + 2. Write the [docs](https://github.com/getsentry/sentry-docs). Answer the following questions: * What does your integration do? Split in two sections: Executive summary at top and exact behavior further down. diff --git a/setup.py b/setup.py index af983ffc30..94c2947307 100644 --- a/setup.py +++ b/setup.py @@ -25,9 +25,18 @@ license="BSD", install_requires=["urllib3>=1.10.0", "certifi"], extras_require={ - "flask": ["flask>=0.8", "blinker>=1.1"], + "flask": ["flask>=0.11", "blinker>=1.1"], "bottle": ["bottle>=0.12.13"], "falcon": ["falcon>=1.4"], + "django": ["django>=1.8"], + "sanic": ["sanic>=0.8"], + "celery": ["celery>=3"], + "beam": ["beam>=2.12"], + "rq": ["0.6"], + "aiohttp": ["aiohttp>=3.5"], + "tornado": ["tornado>=5"], + "sqlalchemy": ["sqlalchemy>=1.2"], + "pyspark": ["pyspark>=2.4.4"], }, classifiers=[ "Development Status :: 5 - Production/Stable", @@ -43,6 +52,7 @@ "Programming Language :: Python :: 3.5", "Programming Language :: Python :: 3.6", "Programming Language :: Python :: 3.7", + "Programming Language :: Python :: 3.8", "Topic :: Software Development :: Libraries :: Python Modules", ], ) diff --git a/tox.ini b/tox.ini index ed48cb2ea2..e44c86c92e 100644 --- a/tox.ini +++ b/tox.ini @@ -32,8 +32,8 @@ envlist = {pypy,py2.7,py3.5,py3.6,py3.7,py3.8}-celery-{4.1,4.2,4.3} {pypy,py2.7}-celery-3 - py2.7-beam-{12,13} - py3.7-beam-{12,13,master} + py2.7-beam-{2.12,2.13} + py3.7-beam-{2.12,2.13,master} # The aws_lambda tests deploy to the real AWS and have their own matrix of Python versions. py3.7-aws_lambda @@ -99,8 +99,8 @@ deps = {py3.5,py3.6}-sanic: aiocontextvars==0.2.1 sanic: aiohttp - beam-12: apache-beam>=2.12.0, <2.13.0 - beam-13: apache-beam>=2.13.0, <2.14.0 + beam-2.12: apache-beam>=2.12.0, <2.13.0 + beam-2.13: apache-beam>=2.13.0, <2.14.0 beam-master: git+https://github.com/apache/beam#egg=apache-beam&subdirectory=sdks/python celery-3: Celery>=3.1,<4.0 From 21aa7b0555f8f57ea71b1d3467b0e5bd93cfb690 Mon Sep 17 00:00:00 2001 From: Markus Unterwaditzer Date: Sun, 24 Nov 2019 19:38:17 +0100 Subject: [PATCH 2/2] doc: Add guidance for writing tests for integrations --- CONTRIBUTING.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9070d725d9..ebec137873 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -44,13 +44,19 @@ The usual release process goes like this: * Allow the user to disable the integration by changing the client. Check `Hub.current.get_integration(MyIntegration)` from within your signal handlers to see if your integration is still active before you do anything impactful (such as sending an event). +2. Write tests. + + * Think about the minimum versions supported, and test each version in a separate env in `tox.ini`. + + * Create a new folder in `tests/integrations/`, with an `__init__` file that skips the entire suite if the package is not installed. + 3. Update package metadata. * We use `extras_require` in `setup.py` to communicate minimum version requirements for integrations. People can use this in combination with tools like Poetry or Pipenv to detect conflicts between our supported versions and their used versions programmatically. Do not set upper-bounds on version requirements as people are often faster in adopting new versions of a web framework than we are in adding them to the test matrix or our package metadata. -2. Write the [docs](https://github.com/getsentry/sentry-docs). Answer the following questions: +4. Write the [docs](https://github.com/getsentry/sentry-docs). Answer the following questions: * What does your integration do? Split in two sections: Executive summary at top and exact behavior further down. @@ -62,5 +68,6 @@ The usual release process goes like this: Tip: Put most relevant parts wrapped in `..` tags for usage from within the Sentry UI. -3. Merge docs after new version has been released (auto-deploys on merge). -4. (optional) Update data in [`sdk_updates.py`](https://github.com/getsentry/sentry/blob/master/src/sentry/sdk_updates.py) to give users in-app suggestions to use your integration. May not be applicable or doable for all kinds of integrations. +5. Merge docs after new version has been released (auto-deploys on merge). + +6. (optional) Update data in [`sdk_updates.py`](https://github.com/getsentry/sentry/blob/master/src/sentry/sdk_updates.py) to give users in-app suggestions to use your integration. May not be applicable or doable for all kinds of integrations.