Sync with global requirements
In addition, the test code was updated to fix a test failure. This failure occurred due to a change of behaviour from the version we were using of cliff, which now differs in version 1.7.0. Change-Id: I06782928414561f7cb4088e385e82c882de4ff46
This commit is contained in:
parent
17c11b1239
commit
f5f4f90e51
|
@ -45,6 +45,8 @@ class WhenTestingBarbicanCLI(test_client.BaseEntityResource):
|
|||
exit_code = _barbican.run(argv=argstr.split())
|
||||
except Exception as exception:
|
||||
exit_message = exception.message
|
||||
except SystemExit as sys_exit_exception:
|
||||
exit_code = sys_exit_exception.code
|
||||
finally:
|
||||
out = stdout.getvalue()
|
||||
os.environ = _old_env
|
||||
|
|
|
@ -1,9 +1,12 @@
|
|||
pbr>=0.5.21,<1.0
|
||||
# The order of packages is significant, because pip processes them in the order
|
||||
# of appearance. Changing the order has an impact on the overall integration
|
||||
# process, which may cause wedges in the gate later.
|
||||
pbr>=0.6,!=0.7,<1.0
|
||||
argparse
|
||||
requests>=1.2.3
|
||||
six>=1.5.2
|
||||
python-keystoneclient>=0.9.0
|
||||
requests>=2.2.0,!=2.4.0
|
||||
six>=1.7.0
|
||||
python-keystoneclient>=0.11.1
|
||||
cliff>=1.7.0 # Apache-2.0
|
||||
oslo.i18n>=1.0.0 # Apache-2.0
|
||||
oslo.serialization>=1.0.0 # Apache-2.0
|
||||
oslo.utils>=1.0.0 # Apache-2.0
|
||||
oslo.i18n>=1.0.0 # Apache-2.0
|
||||
oslo.serialization>=1.0.0 # Apache-2.0
|
||||
oslo.utils>=1.0.0 # Apache-2.0
|
||||
|
|
15
setup.py
15
setup.py
|
@ -1,5 +1,5 @@
|
|||
#!/usr/bin/python
|
||||
# Copyright (c) 2013 OpenStack, LLC.
|
||||
#!/usr/bin/env python
|
||||
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
|
@ -17,7 +17,14 @@
|
|||
# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
|
||||
import setuptools
|
||||
|
||||
# In python < 2.7.4, a lazy loading of package `pbr` will break
|
||||
# setuptools if some other modules registered functions in `atexit`.
|
||||
# solution from: http://bugs.python.org/issue15881#msg170215
|
||||
try:
|
||||
import multiprocessing # noqa
|
||||
except ImportError:
|
||||
pass
|
||||
|
||||
setuptools.setup(
|
||||
setup_requires=['pbr'],
|
||||
pbr=True,
|
||||
)
|
||||
pbr=True)
|
||||
|
|
|
@ -1,10 +1,13 @@
|
|||
# The order of packages is significant, because pip processes them in the order
|
||||
# of appearance. Changing the order has an impact on the overall integration
|
||||
# process, which may cause wedges in the gate later.
|
||||
coverage>=3.6
|
||||
discover
|
||||
hacking>=0.7.0
|
||||
httpretty>=0.8.0
|
||||
mock>=1.0.1
|
||||
testrepository>=0.0.17
|
||||
testtools>=0.9.32,<0.9.35
|
||||
httpretty>=0.8.0,!=0.8.1,!=0.8.2,!=0.8.3
|
||||
mock>=1.0
|
||||
testrepository>=0.0.18
|
||||
testtools>=0.9.34
|
||||
|
||||
# Documentation build requirements
|
||||
sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
|
||||
|
|
Loading…
Reference in New Issue