OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins as a part of the Git hosting and code review systems migration detailed in these mailing list posts: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html Attempts have been made to correct repository namespaces and hostnames based on simple pattern matching, but it's possible some were updated incorrectly or missed entirely. Please reach out to us via the contact information listed at https://opendev.org/ with any questions you may have.
|1 month ago|
|doc/source||1 year ago|
|hacking||8 months ago|
|integration-test||1 month ago|
|releasenotes||1 year ago|
|.gitignore||10 months ago|
|.gitreview||1 month ago|
|.mailmap||6 years ago|
|.stestr.conf||10 months ago|
|.zuul.yaml||1 month ago|
|CONTRIBUTING.rst||4 years ago|
|HACKING.rst||8 months ago|
|LICENSE||6 years ago|
|MANIFEST.in||5 years ago|
|README.rst||5 months ago|
|lower-constraints.txt||10 months ago|
|requirements.txt||1 year ago|
|setup.cfg||5 months ago|
|setup.py||1 year ago|
|test-requirements.txt||10 months ago|
|tox.ini||4 months ago|
hacking is a set of flake8 plugins that test and enforce the OpenStack StyleGuide
Hacking pins its dependencies, as a new release of some dependency can break hacking based gating jobs. This is because new versions of dependencies can introduce new rules, or make existing rules stricter.
hacking is available from pypi, so just run:
pip install hacking
This will install specific versions of
flake8 with the
Hacking started its life out as a text file in Nova's first commit. It was initially based on the Google Python Style Guide, and over time more OpenStack specific rules were added. Hacking serves several purposes:
Initially the hacking style guide was enforced manually by reviewers, but this was a big waste of time so hacking, the tool, was born to automate the process and remove the extra burden from human reviewers.
hacking uses the
major.minor.maintenance release notation, where maintenance releases cannot contain new checks. This way projects can gate on hacking by pinning on the
major.minor number while accepting maintenance updates without being concerned that a new version will break the gate with a new check.
For example a project can depend on
hacking>=0.10.0,<0.11.0, and can know that
0.10.1 will not fail in places where
Each check is a pep8 plugin so read
The focus of new or changed rules should be to do one of the following
But, as always, remember that these are Guidelines. Treat them as such. There are always times for exceptions. All new rules should support noqa.
If a check needs to be staged in, or it does not apply to every project or its branch, it can be added as off by default.
Some of the available checks are disabled by default. These checks are:
To enable these checks, edit the
flake8 section of the
tox.ini file. For example to enable H106 and H203:
hacking supports having local changes in a source tree. They can be configured to run in two different ways. They can be registered individually, or with a factory function.
For individual registration, put a comma separated list of pep8 compatible check functions into the hacking section of tox.ini. E.g.:
Alternately, you can specify the location of a callable that will be called at registration time and will be passed the registration function. The callable should expect to call the passed in function on everything if wants to register. Such as: