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,
- 56b5aed08c/setup.cfg (L13)
Also indicates that we support python 3.9.
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 .
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
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.
Signed-off-by: Doug Hellmann <firstname.lastname@example.org>
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
Solving this for now with the removal of the comment itself.
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.
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.
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
Make sure we specify 3.4 everywhere needed
Move the requirements definitions and documentation files to the
standard places used by other OpenStack projects so our doc publishing
jobs will work.
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
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.
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.