Python Dependencies

Unlike our frontend JavaScript story, where we're generally very happy pulling in dependencies, we're much more conservative on the backend. Any dependency we pull in might require us to eventually (temporarily) fork and vendor it if the upstream project no longer supports our version of Python.

Additionally, all these dependencies run on the server, making them riskier as they have direct access to customer data if they turn out to be malicious.

Adding a new dependency

Any new dependency needs to be thoroughly reviewed and approved by owners-python-build.

This group is already automatically tagged in your PR to sentry or getsentry as soon as you edit relevant files. For other repos you might need to do it manually.

Depending on forks

If you need to make modifications to a dependency and need to deploy the result before it is accepted upstream, you can fork the dependency.

Depending on forks is generally discouraged unless necessary, and you should make sure that the changes in your fork are not required for self-hosted to function, because they won't be included in the PyPI distribution of Sentry.

1. Fork into the getsentry organization.
2. Depend on the fork using library-name @ https://github.com/getsentry/<repo>/archive/<40 char sha>.zip in getsentry's requirements-base.txt.
3. The requirement in sentry stays the same, because we upload sentry to PyPI, and PyPI does not allow us to depend on URLs.

Updating Dependencies

We generate frozen requirements files from requirements-base.txt and requirements-dev.txt, so if you're updating dependencies, change those source files and run make freeze-requirements, which will refreeze.

Note that many of the pins in the source files are lower bounds to encourage updating to latest versions, though this isn't a strict requirement. For example if you're upgrading something like Django, you will want to have a tighter pin.

Unclear?

If you have questions about dependencies, ask owners-python-build or in #discuss-dev-infra.