In Zed cycle testing runtime, we are targetting to drop the
python 3.6/3.7 support, project started adding python 3.8 as minimum,
example nova:
- 56b5aed08c/setup.cfg (L13)
Also indicates that we support python 3.9.
Change-Id: I1bdec397b1ac563b09174763c20e8a91e5f86143
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I394e12bf1816e4e23e4f547db4bae89547af7989
The documentation jobs now look for requirements in
doc/requirements.txt and do not use tox for release notes. Move the
dependency list from setup.cfg to the new file and update tox.ini so
the developer experience is consistent with what the CI system does.
Change-Id: I739c9eba21d1b9a680d6b0e9cc6a4cbaca56e543
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
reno is not used for testing so it should not be in test-requirements.txt .
Move it to the optional docs requirements.
Change-Id: Idf09d2fe9632882a830311a1ab1fe28b72f1d5d9
Looks like the requirements bot can not handle comments correctly. Commit
95f3944a60 removed the correct indent and commit 6b31e1de17 added
a duplicate openstackdocstheme requirement instead of updating the
available one.
Solving this for now with the removal of the comment itself.
Change-Id: I6e25e8d626254b112b3ba5e525d89791ea4a25f2
stevedore is a library that is used outside of OpenStack, too. Having
a build requirement that needs something OpenStack specific makes
life in cases (eg. for downstream packagers) more difficult.
So let's make openstackdocstheme an optional requirement.
Change-Id: Ic8cc577e617e5da699f9dc43830183005bd2ee66
The gating on python 3.4 is restricted to <= Mitaka. This is due
to the change from Ubuntu Trusty to Xenial, where only python3.5
is available. There is no need to continue to keep these settings.
Change-Id: I8899429c4bdbc723c448624be49cc27343798f25
Now that there is a passing gate job, we can claim support for
Python 3.5 in the classifier. This patch also adds the convenience
py35 venv.
Change-Id: I13d2453d9bd15ca3320968aa30f0fe9db13d717d
We have decided to remove Python 2.6 support, this commit
removes Python 2.6 classifier before dropping any Python
2.6 support in code.
Change-Id: I30a85c832dc5edb28d8e0706bb3a51caecca18ed
By setting this pbr option in setup.cfg, the doc build will fail in case
of any warnings or errors occur during the build process.
Change-Id: I861b6de50aaa5a30db1b18474b2554743a9968c7
We have CI for 2.6, 2.7, 3.4. So make sure
all references to other versions are removed and
all 3 versions above are correctly mentioned where
required.
Make sure we specify 3.4 everywhere needed
Change-Id: I2c90bccfc7495bf8197319196a12b2a8bd0519f1
Move the requirements definitions and documentation files to the
standard places used by other OpenStack projects so our doc publishing
jobs will work.
Change-Id: Iea630d827976fe517afacf4e373b3a125efff9c9
When using the DriverManager class, if the driver fails to load, it's
actually better by default to re-raise the exception. It's not something
possible when loading multiple extension, but it's safe to do so with
drivers. This just changes the default behaviour, and it can still be
overridden.
The upside of that change is that when you try to load a driver that
cannot be loaded because of missing dependency, you actually get the
ImportError backtrace on your screen rather than the useless:
RuntimeError: No 'foo' driver found, looking for 'bar'
which doesn't help at all. And the default mechanism that logs via
LOG.error() doesn't print anything at the screen if the application
didn't configure the logging subsystem.
Change-Id: I67d9e13a07c822c54dd16ac9ae7716747a24dd73
When entrypoints are loaded it is sometimes useful
to be able to do more than LOG the failure that could
be emitted from the plugin failing to be constructed,
allowing the manager classes to be provided a callback
that can be called when such extension fails to load
is useful to track these types of failures.
Change-Id: Idc7e55ade6b3f80c348123fbceea64425d7d3508
Hervé Beraud