darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2026-08-14 23:07:49 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
87d7ed21a22828342cb959d8d4e101a653dcbeb2
notifications-api/requirements.txt

87 lines
1.9 KiB
Plaintext
Raw Normal View History

Make pyup ignore requirements.txt We don't want pyup.io upgrading sub-dependencies listed in the requirements.txt file since it does it whenever a new version is available regardless of what our application dependencies require.
2018-07-30 16:22:20 +01:00
# pyup: ignore file
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
# This file is autogenerated. Do not edit it manually.
# Run `make freeze-requirements` to update requirements.txt
# with package version changes made in requirements-app.txt
Update cffi from 1.12.2 to 1.12.3
2019-04-24 16:05:51 +01:00
cffi==1.12.3
Revert "Celery 4"
2018-10-09 13:27:49 +01:00
celery==3.1.26.post2 # pyup: <4
update dependencies
2017-08-18 15:39:39 +01:00
docopt==0.6.2
upgrade flask-bcrypt to 0.7.1 this uses bcrypt directly rather than using the wrapper python-bcrypt. WARNING! You'll need to update your local install by running: ``` pip uninstall python-bcrypt pip install flask-bcrypt==0.7.1 ```
2017-09-11 15:47:10 +01:00
Flask-Bcrypt==0.7.1
freeze-requirements
2019-05-09 10:55:41 +01:00
flask-marshmallow==0.10.1
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
Flask-Migrate==2.5.2
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
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
Flask==1.1.1
take advantage of click's type validation/coercion (saves us having to write the stuff ourselves). Also adds a small click plugin to do datetime parsing. Sample output: ``` [leohemsted:~/dev/api]$ flask command create_provider_rates --help Usage: flask command create_provider_rates [OPTIONS] Backfill rates for a given provider Options: -p, --provider_name [mmg|firetext|ses] [required] -c, --cost FLOAT Cost (pence) per message including decimals [required] -d, --valid_from DATE [required] --help Show this message and exit. [leohemsted:~/dev/api]$ flask command create_provider_rates -p ses -c 1.234 -d invalid Usage: flask command create_provider_rates [OPTIONS] Error: Invalid value for "-d" / "--valid_from": Could not parse datetime string "invalid" formatted as %Y-%m-%dT%H:%M:%S ```
2017-11-28 11:10:19 +00:00
click-datetime==0.2
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
eventlet==0.25.1
Stop pyup from trying to upgrade gunicorn
2019-04-10 11:32:04 +01:00
gunicorn==19.7.1 # pyup: ignore, >19.8 breaks eventlet patching
update dependencies
2017-08-18 15:39:39 +01:00
iso8601==0.1.12
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
jsonschema==3.0.2
marshmallow-sqlalchemy==0.17.0
pin marshmallow and update flask error handling
2019-09-04 12:14:28 +01:00
marshmallow==2.20.2 # pyup: <3 throws errors
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
psycopg2-binary==2.8.3
reqs bump
2019-02-06 16:49:56 +00:00
PyJWT==1.7.1
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
SQLAlchemy==1.3.8
Added python client to dependencies
2015-12-14 12:58:49 +00:00
reqs bump
2019-02-06 16:49:56 +00:00
notifications-python-client==5.3.0
Use the new version of the notifications-python-client. This version no longer adds the req and pay to the claims of the jwt. The change is backward compatible so an older client that sends a jwt with the extra claims will pass authentication. Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well.
2016-04-14 18:12:33 +01:00
Add awslogs logging for PaaS
2017-02-13 18:04:08 +00:00
# PaaS
awscli-cwlogs>=1.4,<1.5
pin itsdangerous to v0.24 itsdangerous v1 uses sha512 instead of sha1 to sign and unsign its strings. Pin to 0.24 until we figure a migration plan, since it's used in a few places (In the DB, in email tokens, and sending blobs to celery at least).
2018-10-22 16:57:12 +01:00
# Putting upgrade on hold due to v1.0.0 using sha512 instead of sha1 by default
itsdangerous==0.24 # pyup: <1.0.0
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
git+https://github.com/alphagov/notifications-utils.git@36.1.0#egg=notifications-utils==36.1.0
Refactor s3upload s3upload function has been moved to notifications-utils. https://github.com/alphagov/notifications-utils/pull/138 must be merge first.
2017-04-06 10:27:13 +01:00
Revert "Celery 4"
2018-10-09 13:27:49 +01:00
git+https://github.com/alphagov/boto.git@2.43.0-patch3#egg=boto==2.43.0-patch3
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
## The following requirements were added by pip freeze:
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
alembic==1.2.1
Revert "Celery 4"
2018-10-09 13:27:49 +01:00
amqp==1.4.9
anyjson==0.3.3
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
attrs==19.3.0
awscli==1.16.263
Bump utils to add alt text to email branding Utils 33.0.0 adds alt text to email branding - the HTMLEmailTemplate now initializes slightly differently as a result (with both `branding_name` and `branding_text`).
2019-06-25 16:53:07 +01:00
bcrypt==3.1.7
Revert "Celery 4"
2018-10-09 13:27:49 +01:00
billiard==3.3.0.23
Bump utils Brings in: - [ ] https://github.com/alphagov/notifications-utils/pull/592
2019-03-18 14:38:09 +00:00
bleach==3.1.0
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
boto3==1.9.221
botocore==1.12.253
certifi==2019.9.11
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
chardet==3.0.4
Lock botocore library to <1.11.0 Using version 1.11.0 or above causes an error with the moto library where it makes real HTTP requests instead of mocking them: https://github.com/spulec/moto/issues/1793 Until this is resolved, botocore needs to be locked. This copies the approach the Digital Marketplace team took to the same problem: https://github.com/alphagov/digitalmarketplace-utils/pull/452
2018-09-27 14:35:08 +01:00
Click==7.0
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
colorama==0.4.1
Update requirements.txt
2019-04-17 11:35:42 +01:00
dnspython==1.16.0
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
docutils==0.15.2
Bump utils to 32.0.1 This updates requirements and brings in the change to preserve trailing semicolons on URLs.
2019-06-03 16:08:19 +01:00
flask-redis==0.4.0
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
future==0.18.1
Bump utils to 30.3.1 Brings in stripping of the line separator character from emails. https://github.com/alphagov/notifications-utils/pull/531
2018-09-26 10:16:45 +01:00
greenlet==0.4.15
Bump utils to 30.7.2
2019-01-02 15:45:06 +00:00
idna==2.8
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
Jinja2==2.10.3
Bump utils Brings in: - [ ] https://github.com/alphagov/notifications-utils/pull/592
2019-03-18 14:38:09 +00:00
jmespath==0.9.4
Revert "Celery 4"
2018-10-09 13:27:49 +01:00
kombu==3.0.37
bump utils also remove the `read().splitlines()` pattern from csv.reader usage, as it's redundant. also add .vscode to gitignore to accomodate my hipster IDE choices, and add some lines to pytest.ini so just running `py.test` uses some useful flags
2019-08-02 12:41:03 +01:00
Mako==1.1.0
Bump utils Brings in: - [ ] https://github.com/alphagov/notifications-utils/pull/592
2019-03-18 14:38:09 +00:00
MarkupSafe==1.1.1
bump utils (inc redis bump)
2019-01-08 14:15:20 +00:00
mistune==0.8.4
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
monotonic==1.5
orderedset==2.0.1
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
phonenumbers==8.10.17
freeze requirements and bump utils
2019-09-04 10:55:22 +01:00
pyasn1==0.4.7
Bump utils to 30.3.1 Brings in stripping of the line separator character from emails. https://github.com/alphagov/notifications-utils/pull/531
2018-09-26 10:16:45 +01:00
pycparser==2.19
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
PyPDF2==1.26.0
bump utils also remove the `read().splitlines()` pattern from csv.reader usage, as it's redundant. also add .vscode to gitignore to accomodate my hipster IDE choices, and add some lines to pytest.ini so just running `py.test` uses some useful flags
2019-08-02 12:41:03 +01:00
pyrsistent==0.15.4
reqs bump
2019-02-06 16:49:56 +00:00
python-dateutil==2.8.0
Bump utils to 30.7.5 Brings in: - [x] https://github.com/alphagov/notifications-utils/pull/572
2019-02-01 09:32:43 +00:00
python-editor==1.0.4
Bump utils to 32.0.1 This updates requirements and brings in the change to preserve trailing semicolons on URLs.
2019-06-03 16:08:19 +01:00
python-json-logger==0.1.11
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
pytz==2019.3
PyYAML==5.1.2
redis==3.3.11
Bump utils to 32.0.1 This updates requirements and brings in the change to preserve trailing semicolons on URLs.
2019-06-03 16:08:19 +01:00
requests==2.22.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
rsa==3.4.2
Bump utils to add alt text to email branding Utils 33.0.0 adds alt text to email branding - the HTMLEmailTemplate now initializes slightly differently as a result (with both `branding_name` and `branding_text`).
2019-06-25 16:53:07 +01:00
s3transfer==0.2.1
Bump utils to 30.7.2
2019-01-02 15:45:06 +00:00
six==1.12.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
smartypants==2.0.1
bump utils (inc redis bump)
2019-01-08 14:15:20 +00:00
statsd==3.3.0
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
urllib3==1.25.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
webencodings==0.5.1
Bump utils to bring in changes to logging Freezing the requirements changes the Werkzeug version to 0.16.0, which requires a change in how we import an exception (https://github.com/pallets/werkzeug/blob/master/CHANGES.rst#version-0160)
2019-10-23 16:14:39 +01:00
Werkzeug==0.16.0
Reference in New Issue Copy Permalink