d0bfb17caa
Inside WSME's parse_isodatetime there's a switch that checks for the existence of python_dateutil. If this does not exist, it falls back on its own ISO parsing, which does not support timezones, and causes havoc in our API. This adds the python_datetime dependency (BSD License) that triggers this switch. An unrelated change has been submitted to the WSME project to handle timezone parsing: https://review.openstack.org/#/c/161013/ Change-Id: Ib1bbe1118cc04f7622d1d0ef3993594d5bd102f7
30 lines
514 B
Plaintext
30 lines
514 B
Plaintext
pbr>=0.6,!=0.7,<1.0
|
|
jsonschema>=2.0.0,<3.0.0
|
|
argparse
|
|
alembic>=0.4.1
|
|
Babel>=1.3
|
|
iso8601>=0.1.9
|
|
oauthlib>=0.6
|
|
oslo.config>=1.2.1
|
|
oslo.context>=0.1.0
|
|
oslo.utils>=1.2.0
|
|
pecan>=0.4.5
|
|
oslo.db>=0.2.0
|
|
oslo.log>=0.1.0
|
|
pika>=0.9.14
|
|
python-openid
|
|
PyYAML>=3.1.0
|
|
requests>=1.1
|
|
six>=1.7.0
|
|
SQLAlchemy>=0.9.7,<=0.9.99
|
|
WSME>=0.6
|
|
sqlalchemy-migrate>=0.9.1,!=0.9.2
|
|
SQLAlchemy-FullText-Search
|
|
eventlet>=0.13.0
|
|
stevedore>=1.0.0
|
|
tzlocal>=1.1.2
|
|
email>=4.0.2
|
|
Jinja2>=2.7.3
|
|
PyMySQL>=0.6.2,!=0.6.4
|
|
apscheduler>=3.0.1
|
|
python_dateutil>=2.4.0 |