Files
notifications-api/requirements.txt

281 lines
5.7 KiB
Plaintext
Raw Permalink Normal View History

#
# This file is autogenerated by pip-compile with python 3.9
# To update, run:
#
# pip-compile requirements.in
#
alembic==1.7.7
# via flask-migrate
amqp==5.1.1
# via kombu
arrow==1.2.2
# via isoduration
async-timeout==4.0.2
# via redis
attrs==21.4.0
# via jsonschema
awscli==1.24.8
2022-04-12 14:13:29 +01:00
# via awscli-cwlogs
awscli-cwlogs==1.4.6
# via -r requirements.in
bcrypt==3.2.2
# via flask-bcrypt
beautifulsoup4==4.11.1
# via -r requirements.in
billiard==3.6.4.0
# via celery
bleach==4.1.0
# via notifications-utils
blinker==1.4
# via gds-metrics
boto3==1.23.8
# via notifications-utils
botocore==1.26.8
# via
# awscli
# boto3
# s3transfer
2022-05-17 10:53:06 +01:00
cachetools==5.1.0
# via
# -r requirements.in
# notifications-utils
celery[sqs]==5.2.6
# via -r requirements.in
certifi==2022.5.18.1
# via
# pyproj
# requests
cffi==1.15.0
# via
# -r requirements.in
# bcrypt
charset-normalizer==2.0.12
# via requests
click==8.1.3
# via
# celery
# click-datetime
# click-didyoumean
# click-plugins
# click-repl
# flask
click-datetime==0.2
# via -r requirements.in
click-didyoumean==0.3.0
# via celery
click-plugins==1.1.1
# via celery
click-repl==0.2.0
# via celery
colorama==0.4.4
# via awscli
deprecated==1.2.13
# via redis
dnspython==2.2.1
# via eventlet
docopt==0.6.2
# via notifications-python-client
docutils==0.16
# via awscli
eventlet==0.33.1
# via gunicorn
2022-05-17 10:36:16 +01:00
flask==2.1.2
# via
# -r requirements.in
# flask-bcrypt
# flask-marshmallow
# flask-migrate
# flask-redis
# gds-metrics
# notifications-utils
flask-bcrypt==1.0.1
# via -r requirements.in
flask-marshmallow==0.14.0
# via -r requirements.in
flask-migrate==3.1.0
# via -r requirements.in
flask-redis==0.4.0
# via notifications-utils
flask-sqlalchemy @ git+https://github.com/mitsuhiko/flask-sqlalchemy.git@500e732dd1b975a56ab06a46bd1a20a21e682262
# via
# -r requirements.in
# flask-migrate
fqdn==1.5.1
# via jsonschema
gds-metrics @ git+https://github.com/alphagov/gds_metrics_python.git@6f1840a57b6fb1ee40b7e84f2f18ec229de8aa72
# via -r requirements.in
geojson==2.5.0
# via notifications-utils
govuk-bank-holidays==0.11
# via notifications-utils
greenlet==1.1.2
# via
# eventlet
# sqlalchemy
gunicorn @ git+https://github.com/benoitc/gunicorn.git@1299ea9e967a61ae2edebe191082fd169b864c64
# via -r requirements.in
idna==3.3
# via
# jsonschema
# requests
iso8601==1.0.2
# via -r requirements.in
isoduration==20.11.0
# via jsonschema
itsdangerous==2.1.2
# via
# -r requirements.in
# flask
# notifications-utils
jinja2==3.1.2
# via
# flask
# notifications-utils
jmespath==1.0.0
# via
# boto3
# botocore
jsonpointer==2.3
# via jsonschema
2022-05-17 10:45:28 +01:00
jsonschema[format]==4.5.1
# via -r requirements.in
kombu==5.2.4
# via celery
lxml==4.9.1
# via -r requirements.in
mako==1.2.0
# via alembic
markupsafe==2.1.1
# via
# jinja2
# mako
marshmallow==3.15.0
# via
# -r requirements.in
# flask-marshmallow
# marshmallow-sqlalchemy
marshmallow-sqlalchemy==0.28.0
# via -r requirements.in
2019-01-08 14:15:20 +00:00
mistune==0.8.4
# via notifications-utils
notifications-python-client==6.3.0
# via -r requirements.in
notifications-utils @ git+https://github.com/alphagov/notifications-utils.git@56.0.0
# via -r requirements.in
orderedset==2.0.3
# via notifications-utils
packaging==21.3
# via
# bleach
# marshmallow
# redis
phonenumbers==8.12.48
# via notifications-utils
prometheus-client==0.14.1
# via
# -r requirements.in
# gds-metrics
prompt-toolkit==3.0.29
# via click-repl
psycopg2-binary==2.9.3
# via -r requirements.in
2019-11-18 15:48:38 +00:00
pyasn1==0.4.8
# via rsa
pycparser==2.21
# via cffi
2022-05-17 10:49:30 +01:00
pyjwt==2.4.0
# via
# -r requirements.in
# notifications-python-client
pyparsing==3.0.9
# via packaging
pypdf2==2.0.0
# via notifications-utils
pyproj==3.3.1
# via notifications-utils
pyrsistent==0.18.1
# via jsonschema
python-dateutil==2.8.2
# via
# arrow
# awscli-cwlogs
# botocore
python-dotenv==0.20.0
# via -r requirements.in
python-json-logger==2.0.2
# via notifications-utils
pytz==2022.1
# via
# celery
# notifications-utils
pyyaml==5.4.1
# via
# awscli
# notifications-utils
redis==4.3.1
# via flask-redis
requests==2.27.1
# via
# awscli-cwlogs
# govuk-bank-holidays
# notifications-python-client
# notifications-utils
rfc3339-validator==0.1.4
# via jsonschema
rfc3987==1.3.8
# via jsonschema
2021-04-19 11:36:04 +01:00
rsa==4.7.2
# via awscli
s3transfer==0.5.2
# via
# awscli
# boto3
shapely==1.8.2
# via notifications-utils
six==1.16.0
# via
# awscli-cwlogs
# bleach
# click-repl
# eventlet
# flask-marshmallow
# python-dateutil
# rfc3339-validator
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
smartypants==2.0.1
# via notifications-utils
soupsieve==2.3.2.post1
# via beautifulsoup4
sqlalchemy==1.4.36
# via
# -r requirements.in
# alembic
# marshmallow-sqlalchemy
2019-01-08 14:15:20 +00:00
statsd==3.3.0
# via notifications-utils
uri-template==1.2.0
# via jsonschema
urllib3==1.26.9
# via
# botocore
# requests
vine==5.0.0
# via
# amqp
# celery
# kombu
wcwidth==0.2.5
# via prompt-toolkit
webcolors==1.12
# via jsonschema
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
webencodings==0.5.1
# via bleach
2022-03-09 17:22:11 +00:00
werkzeug==2.0.3
# via
# -r requirements.in
# flask
wrapt==1.14.1
# via deprecated
# The following packages are considered to be unsafe in a requirements file:
# setuptools