darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2025-12-25 01:41:34 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
4b4122a773f55d02027dd6737d54d3f810ac3ade
notifications-api/requirements.in

39 lines
1.1 KiB
Plaintext
Raw Normal View History

Pin all application requirements in requirements.txt The list of top-level dependencies is moved to requirements-app.txt, which is used by `make freeze-requirements` to generate the full list of requirements in requirements.txt. This is based on alphagov/digitalmarketplace-api#615, so rationale from that PR applies here. We had a problem with unpinned packages on new deployments leading to failed tests (e.g. alphagov/notifications-admin#2144) which is why we're implementing this now. After re-evaluating pipenv again, this still seems like the least disruptive approach: * pyup.io has experimental support for Pipfile, but doesn't respect version ranges or updating hashes in the lock file * CloudFoundry buildpack recognizes and supports Pipfiles out of the box, but the support is relatively new. For example until recently CF would install dev packages during deployment. It's also based on generating a requirements file from the Pipfile, which doesn't properly support pinning VCS dependencies (eg it doesn't set the #egg= version, meaning pip will not upgrade the package if it's already installed). * pipenv has a strict dependency resolution algorithm, which doesn't appear to be well documented and can cause some unexpected failures. For example, pipenv doesn't seem to be able to install `awscli-cwlogs` package at all, believing it to have a version conflict for `botocore` (which it doesn't list as a direct dependency) while neither `pip` nor `pip-tools` highlight any issues with it. * While trying out `pipenv install` on our list of dependencies it would regularly fail to install utils with a "Will try again." message. While the installation succeeds after a retry, this doesn't inspire confidence. * The switch to Pipfile and pipenv-managed virtualenvs requires a series of changes to `make` targets and scripts - replacing `pip install` with `pipenv`, removing references to requirements files and prefixing commands with `pipenv run`. While it's likely to simplify the overall process of managing dependencies, it would require time to properly implement across our applications and environments (Jenkins, PaaS, docker containers, and dev machines).
2018-07-10 14:50:30 +01:00
# Run `make freeze-requirements` to update requirements.txt
# with package version changes made in requirements-app.txt
Update cffi from 1.14.4 to 1.14.5
2021-03-03 13:00:03 +00:00
cffi==1.14.5
Bump Celery to latest version This brings in the version 5.2.1 of Kombu, which fixes a security vulnerability: > Celery 5.2.0 includes 'kombu' v5.2.1, which includes dependencies > updates that resolve security issues. — https://pyup.io/repos/github/alphagov/notifications-api/commits/?page=1#b654c27699a5164cbbe50e042d5d34141f560255 This is the commit from Kombu: https://github.com/celery/kombu/commit/f3b04558fa0df4ecc383c93e0b3b300d95e17c47 I believe the dependency of Kombu which has issues is urllib3, which has two open advisories for versions less than 1.26.5: - https://github.com/urllib3/urllib3/security/advisories/GHSA-q2q7-5pp4-w6pg - https://github.com/urllib3/urllib3/security/advisories/GHSA-5phf-pp7p-vc2r
2021-11-15 11:12:33 +00:00
celery[sqs]==5.2.0
Pin all application requirements in requirements.txt The list of top-level dependencies is moved to requirements-app.txt, which is used by `make freeze-requirements` to generate the full list of requirements in requirements.txt. This is based on alphagov/digitalmarketplace-api#615, so rationale from that PR applies here. We had a problem with unpinned packages on new deployments leading to failed tests (e.g. alphagov/notifications-admin#2144) which is why we're implementing this now. After re-evaluating pipenv again, this still seems like the least disruptive approach: * pyup.io has experimental support for Pipfile, but doesn't respect version ranges or updating hashes in the lock file * CloudFoundry buildpack recognizes and supports Pipfiles out of the box, but the support is relatively new. For example until recently CF would install dev packages during deployment. It's also based on generating a requirements file from the Pipfile, which doesn't properly support pinning VCS dependencies (eg it doesn't set the #egg= version, meaning pip will not upgrade the package if it's already installed). * pipenv has a strict dependency resolution algorithm, which doesn't appear to be well documented and can cause some unexpected failures. For example, pipenv doesn't seem to be able to install `awscli-cwlogs` package at all, believing it to have a version conflict for `botocore` (which it doesn't list as a direct dependency) while neither `pip` nor `pip-tools` highlight any issues with it. * While trying out `pipenv install` on our list of dependencies it would regularly fail to install utils with a "Will try again." message. While the installation succeeds after a retry, this doesn't inspire confidence. * The switch to Pipfile and pipenv-managed virtualenvs requires a series of changes to `make` targets and scripts - replacing `pip install` with `pipenv`, removing references to requirements files and prefixing commands with `pipenv run`. While it's likely to simplify the overall process of managing dependencies, it would require time to properly implement across our applications and environments (Jenkins, PaaS, docker containers, and dev machines).
2018-07-10 14:50:30 +01:00
Flask-Bcrypt==0.7.1
Update flask-marshmallow from 0.11.0 to 0.14.0
2020-12-09 13:00:04 +00:00
flask-marshmallow==0.14.0
Update flask-migrate from 2.5.3 to 2.7.0
2021-03-03 13:00:03 +00:00
Flask-Migrate==2.7.0
Don't return pagination links for API Message log requests Flask-SQLAlchemy paginate function issues a separate query to get the total count of rows for a given filter. This query (with filters used by the API integration Message log page) is slow for services with large number of notifications. Since Message log page doesn't actually allow users to paginate through the response (it only shows the last 50 messages) we can use limit instead of paginate, which requires passing in another flag from admin to the dao method. `count` flag has been added to `paginate` in March 2018, however there was no release of flask-sqlalchemy since then, so we need to pull the dev version of the package from Github.
2019-01-07 17:12:00 +00:00
git+https://github.com/mitsuhiko/flask-sqlalchemy.git@500e732dd1b975a56ab06a46bd1a20a21e682262#egg=Flask-SQLAlchemy==2.3.2.dev20190108
Revert "Bump utils version for new invalid address character"
2021-06-01 10:53:28 +01:00
Flask==1.1.2
Pin all application requirements in requirements.txt The list of top-level dependencies is moved to requirements-app.txt, which is used by `make freeze-requirements` to generate the full list of requirements in requirements.txt. This is based on alphagov/digitalmarketplace-api#615, so rationale from that PR applies here. We had a problem with unpinned packages on new deployments leading to failed tests (e.g. alphagov/notifications-admin#2144) which is why we're implementing this now. After re-evaluating pipenv again, this still seems like the least disruptive approach: * pyup.io has experimental support for Pipfile, but doesn't respect version ranges or updating hashes in the lock file * CloudFoundry buildpack recognizes and supports Pipfiles out of the box, but the support is relatively new. For example until recently CF would install dev packages during deployment. It's also based on generating a requirements file from the Pipfile, which doesn't properly support pinning VCS dependencies (eg it doesn't set the #egg= version, meaning pip will not upgrade the package if it's already installed). * pipenv has a strict dependency resolution algorithm, which doesn't appear to be well documented and can cause some unexpected failures. For example, pipenv doesn't seem to be able to install `awscli-cwlogs` package at all, believing it to have a version conflict for `botocore` (which it doesn't list as a direct dependency) while neither `pip` nor `pip-tools` highlight any issues with it. * While trying out `pipenv install` on our list of dependencies it would regularly fail to install utils with a "Will try again." message. While the installation succeeds after a retry, this doesn't inspire confidence. * The switch to Pipfile and pipenv-managed virtualenvs requires a series of changes to `make` targets and scripts - replacing `pip install` with `pipenv`, removing references to requirements files and prefixing commands with `pipenv run`. While it's likely to simplify the overall process of managing dependencies, it would require time to properly implement across our applications and environments (Jenkins, PaaS, docker containers, and dev machines).
2018-07-10 14:50:30 +01:00
click-datetime==0.2
Force pyup to ignore eventlet Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
2021-05-11 10:12:01 +01:00
eventlet==0.30.2 # pyup: ignore # 0.31 breaks Gunicorn
Update gunicorn from 20.0.4 to 20.1.0
2021-04-14 14:00:03 +01:00
gunicorn==20.1.0
Update iso8601 from 0.1.13 to 0.1.14
2021-03-03 13:00:04 +00:00
iso8601==0.1.14
Revert "Bump utils version for new invalid address character"
2021-06-01 10:53:28 +01:00
itsdangerous==1.1.0
pyup updates Update cffi from 1.13.1 to 1.13.2 Update jsonschema from 3.1.1 to 3.2.0 Update marshmallow-sqlalchemy from 0.19.0 to 0.21.0 Update marshmallow from 2.20.2 to 3.4.0 Update sqlalchemy from 1.3.10 to 1.3.13 Update notifications-python-client from 5.4.1 to 5.5.1
2020-02-05 13:00:05 +00:00
jsonschema==3.2.0
Pin marshmallow-sqlalchemy below v0.24.0 This was pinned to `<0.24.1` not `<0.24.0` by mistake, which meant pyup was trying to upgrade from version `0.23.1`.
2021-04-19 11:56:02 +01:00
marshmallow-sqlalchemy==0.23.1 # pyup: <0.24.0 # marshmallow v3 throws errors
Update marshmallow from 2.20.5 to 2.21.0
2020-05-22 10:38:27 +01:00
marshmallow==2.21.0 # pyup: <3 # v3 throws errors
Update psycopg2-binary from 2.8.5 to 2.8.6
2020-11-04 13:00:07 +00:00
psycopg2-binary==2.8.6
Update pyjwt from 2.0.0 to 2.0.1
2021-03-03 13:00:05 +00:00
PyJWT==2.0.1
Update sqlalchemy from 1.3.23 to 1.4.10
2021-04-21 14:00:02 +01:00
SQLAlchemy==1.4.10
add more friendly datetime validator to jsonschema add `datetime` format (note, not the built-in `date-time`) to our json schemas. this uses the iso8601 library to try and parse the string. also, move `strict-rfc3339` and `rfc3987` (used by jsonschema to validate `date-time` and `uri` formats respectively from test requirements to regular requirements. if they're not installed, validation silently succeeds, so validation wouldnt reject anything bad on prod, only in unit tests.
2020-07-09 12:59:09 +01:00
strict-rfc3339==0.7
rfc3987==1.3.8
Update cachetools from 4.2.0 to 4.2.1
2021-03-03 13:00:05 +00:00
cachetools==4.2.1
Add translators from CAP to dict Other systems we’re working with won’t easily be adapted to emit JSON instead of CAP, so it’s less work for us to do that conversion. This commit adds to code to parse the XML and turn it into a dict that we can work with, including converting the polygon string into native Python lists.
2021-01-18 10:01:45 +00:00
beautifulsoup4==4.9.3
bump lxml to fix security warning two vulnerabilities in <4.6.5 (GHSL-2021-1037 and GHSL-2021-1038) https://github.com/lxml/lxml/blob/master/CHANGES.txt also removes docopt as we don't use it except for a dev script (which we might not need anyway)
2021-12-14 13:47:38 +00:00
lxml==4.7.1
Bump Werkzeug to version 2.0.2 This is the newest version. Pyup is complaining about vulnerabilities in version 1.0.1, specifically > Werkzeug version 2.0.2 improves the security of the debugger cookies. > "SameSite" attribute is set to "Strict" instead of "None", and the > secure flag is added when on HTTPS. Previously we were using whatever version of Werkzeug that Flask specified this pins it to get rid of the vulnerability without having to upgrade everything at once. We’ve done this for the admin app already: https://github.com/alphagov/notifications-admin/pull/4042/files I suspect the memory usage issues we saw with version 2.0.0 have been fixed in 2.0.2, per this line in the changelog: > Fix memory usage for locals when using Python 3.6 or pre 0.4.17 greenlet versions. > https://github.com/pallets/werkzeug/pull/2212 — https://werkzeug.palletsprojects.com/en/2.0.x/changes/
2021-10-18 15:00:39 +01:00
Werkzeug==2.0.2
Revert werkzeug to the last non-2.0.0 version We observe high memory usage since we bumped it (along with other things) and because it only appears on the API and not on the workers the hypothesis is that Werkzeug is responsible for it.
2021-07-19 14:27:16 +03:00
Update notifications-python-client from 5.7.1 to 6.0.2
2021-03-03 13:00:06 +00:00
notifications-python-client==6.0.2
Pin all application requirements in requirements.txt The list of top-level dependencies is moved to requirements-app.txt, which is used by `make freeze-requirements` to generate the full list of requirements in requirements.txt. This is based on alphagov/digitalmarketplace-api#615, so rationale from that PR applies here. We had a problem with unpinned packages on new deployments leading to failed tests (e.g. alphagov/notifications-admin#2144) which is why we're implementing this now. After re-evaluating pipenv again, this still seems like the least disruptive approach: * pyup.io has experimental support for Pipfile, but doesn't respect version ranges or updating hashes in the lock file * CloudFoundry buildpack recognizes and supports Pipfiles out of the box, but the support is relatively new. For example until recently CF would install dev packages during deployment. It's also based on generating a requirements file from the Pipfile, which doesn't properly support pinning VCS dependencies (eg it doesn't set the #egg= version, meaning pip will not upgrade the package if it's already installed). * pipenv has a strict dependency resolution algorithm, which doesn't appear to be well documented and can cause some unexpected failures. For example, pipenv doesn't seem to be able to install `awscli-cwlogs` package at all, believing it to have a version conflict for `botocore` (which it doesn't list as a direct dependency) while neither `pip` nor `pip-tools` highlight any issues with it. * While trying out `pipenv install` on our list of dependencies it would regularly fail to install utils with a "Will try again." message. While the installation succeeds after a retry, this doesn't inspire confidence. * The switch to Pipfile and pipenv-managed virtualenvs requires a series of changes to `make` targets and scripts - replacing `pip install` with `pipenv`, removing references to requirements files and prefixing commands with `pipenv run`. While it's likely to simplify the overall process of managing dependencies, it would require time to properly implement across our applications and environments (Jenkins, PaaS, docker containers, and dev machines).
2018-07-10 14:50:30 +01:00
# PaaS
bump utils this is to fix pip errors due to bad requirements
2020-12-07 14:28:17 +00:00
awscli-cwlogs==1.4.6
Pin all application requirements in requirements.txt The list of top-level dependencies is moved to requirements-app.txt, which is used by `make freeze-requirements` to generate the full list of requirements in requirements.txt. This is based on alphagov/digitalmarketplace-api#615, so rationale from that PR applies here. We had a problem with unpinned packages on new deployments leading to failed tests (e.g. alphagov/notifications-admin#2144) which is why we're implementing this now. After re-evaluating pipenv again, this still seems like the least disruptive approach: * pyup.io has experimental support for Pipfile, but doesn't respect version ranges or updating hashes in the lock file * CloudFoundry buildpack recognizes and supports Pipfiles out of the box, but the support is relatively new. For example until recently CF would install dev packages during deployment. It's also based on generating a requirements file from the Pipfile, which doesn't properly support pinning VCS dependencies (eg it doesn't set the #egg= version, meaning pip will not upgrade the package if it's already installed). * pipenv has a strict dependency resolution algorithm, which doesn't appear to be well documented and can cause some unexpected failures. For example, pipenv doesn't seem to be able to install `awscli-cwlogs` package at all, believing it to have a version conflict for `botocore` (which it doesn't list as a direct dependency) while neither `pip` nor `pip-tools` highlight any issues with it. * While trying out `pipenv install` on our list of dependencies it would regularly fail to install utils with a "Will try again." message. While the installation succeeds after a retry, this doesn't inspire confidence. * The switch to Pipfile and pipenv-managed virtualenvs requires a series of changes to `make` targets and scripts - replacing `pip install` with `pipenv`, removing references to requirements files and prefixing commands with `pipenv run`. While it's likely to simplify the overall process of managing dependencies, it would require time to properly implement across our applications and environments (Jenkins, PaaS, docker containers, and dev machines).
2018-07-10 14:50:30 +01:00
Bump utils to 53.0.0 Changes: 53.0.0 --- * `notifications_utils.columns.Columns` has moved to `notifications_utils.insensitive_dict.InsensitiveDict` * `notifications_utils.columns.Rows` has moved to `notifications_utils.recipients.Rows` * `notifications_utils.columns.Cell` has moved to `notifications_utils.recipients.Cell` 52.0.0 --- * Deprecate the following unused `redis_client` functions: - `redis_client.increment_hash_value` - `redis_client.decrement_hash_value` - `redis_client.get_all_from_hash` - `redis_client.set_hash_and_expire` - `redis_client.expire` 51.3.1 --- * Bump govuk-bank-holidays to cache holidays for next year.
2022-02-04 10:46:02 +00:00
notifications-utils @ git+https://github.com/alphagov/notifications-utils.git@53.0.0
Add GDSMetrics package As per instructions https://github.com/alphagov/gds_metrics_python The celery workers don't have an HTTP endpoint so no point in trying to get prometheus to scrape them.
2020-04-20 15:59:47 +01:00
bump prometheus-client to 0.7.1 there's multiple performance improvements from prometheus-client 0.2.0. pin this bump while we wait for gds metrics client to increase its dependency
2020-04-24 16:18:44 +01:00
# gds-metrics requires prometheseus 0.2.0, override that requirement as 0.7.1 brings significant performance gains
Update prometheus-client from 0.9.0 to 0.10.1
2021-04-14 14:00:04 +01:00
prometheus-client==0.10.1
Update gds-metrics from 0.2.2 to 0.2.4
2020-08-12 14:00:09 +01:00
gds-metrics==0.2.4
Reference in New Issue Copy Permalink