pep8 was renamed to pycodestyle, so allow that one in order to
be able to transition to it.
The depends-on remove pyflake mentions as most projects adopted
flake8/hacking, we don't need to allow explicit dependencies
on the tools integrated by flake8 (mccabe, pycodestyle/pep8, pyflakes).
Cleanup those from the tests/ files to avoid grep'ing finding them.
Depends-On: I12b5e114c5c6783e9da5cca2818ac9266a00fc87
Depends-On: Ib145e2afa97f441c07fada9c30f0f0e2410870ae
Depends-On: Id44c90ddd4a8a2204fd7ce600097bafbc9469993
Change-Id: If9f30bf39143d5e6fefca794385cafc4456d2197
This enforces consistent spacing in global-requirements.txt
and sorts the specifiers to be always in a specific order
(namely minimum bound first, then exceptions, then upper bound).
Add test coverage for this normalisation.
Change-Id: If41732bfe4476e422bc6b9f9f896eb978db8be84
It is similar to flake8 a generic static code linter
and not necessary for building a binary distribution
of OpenStack, so enforcing a g-r consistent version
seems to be slightly over the top
Change-Id: I3907050a3aaab9d32f9b71c14c47212ba793b58d
We dropped various linters in https://review.openstack.org/#/c/473094/.
This is a follow-up patch on this.
astroid is only used by pylint and both versions are tightly coupled.
If we force astroid===1.3.8, we cannot install newer pylint like 1.7.1.
It looks good to consider astroid as a linter.
Change-Id: Ib2e78f6a22b7d90a3304b13228c16d76982fbbef
This commit adds flake8-import-order to global-requirements.txt. With
this library, we can check whether imports order is along with the
hacking import order template[1] automatically.
Of course, we can check import orders by manual. However it is not fun
and we sometimes mistake. And we have H306 rule for checking import
orders but it only checks alphabetic order not for stdlibs or not.
[1] http://docs.openstack.org/developer/hacking/#import-order-template
* Is the library actively maintained?
Yes. This has been released constantly and maintained by Python Code
Quality Authority. http://meta.pycqa.org/en/latest/management.html
* Is the library good code?
Yes. It's simple enough.
* Is the library python 3 compatible?
Yes.
* Is the library license compatible?
Yes, the library is licensed as MIT.
* Is the library already packaged in the distros we target (Ubuntu
latest / Fedora latest)?
No. It's on pypi.
* Is the function of this library already covered by other libraries
in global-requirements.txt?
No.
* Is the library required for OpenStack project or related dev or
infrastructure setup? Which?
Tempest at this point: Iff75ebec42b295870edd1c04001adfb17460a682
Change-Id: Ia2140f5566ce169b076ffa5c9ebfbdbfc41e5bed
Go ahead and manage reno like our other dependencies.
Change-Id: I496adf3df5ff3d349f96c81da6ec8221595b6fa8
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
PEP257 [1] "documents semantics and conventions associated with Python
docstrings." The pep257 package [2] is "static analysis tool for
checking compliance with Python PEP 257." The flake8_docstrings module
allows us to consume the pep257 package as a flake8 plugin.
[1]: https://www.python.org/dev/peps/pep-0257/
[2]: https://pypi.python.org/pypi/pep257
[3]: https://pypi.python.org/pypi/flake8-docstrings
Consuming projects
==================
Adoption has been proposed to the several keystone projects
including:
- openstack/pycadf
- openstack/keystone
- openstack/keystonemiddleware
- openstack/keystoneauth-saml2
- openstack/keystoneauth
- openstack/python-keystoneclient
- openstack/python-keystoneclient-kerberos
Each of these proposed changes shares the same Change-Id:
http://bit.ly/1jMJvpe
Each of the above patches adds flake8_docstrings as a dependency, but
ignores PEP257 checks which the project is currently failing (in the
near term, this gates against introducing regressions on the subset of
checks which we are currently passing).
The following series of patches proposed against keystone proceeds to
fix one violation at a time and results in increased coverage by pep257:
- https://review.openstack.org/#/c/229689/
- https://review.openstack.org/#/c/229837/
- https://review.openstack.org/#/c/229839/
- https://review.openstack.org/#/c/229853/
- https://review.openstack.org/#/c/229855/
- https://review.openstack.org/#/c/229857/
- https://review.openstack.org/#/c/229865/
- https://review.openstack.org/#/c/229887/
- https://review.openstack.org/#/c/229898/
- https://review.openstack.org/#/c/229916/
Is the library actively maintained?
===================================
flake8_docstrings is maintained by Ian Cordasco (sigmavirus24), a
glance-core reviewer. Given that this project is a wrapper around
pep257, I wouldn't expect much activity in this project, but the latest
release was January 2015. Commit history:
https://gitlab.com/pycqa/flake8-docstrings/commits/master
pep257's last release was July 2015 and it's commit history shows that
it is actively maintained by a small group of contributors:
https://github.com/GreenSteam/pep257/commits/master
Is the library good code?
=========================
flake8_docstrings is comprised of a single, trivial class to expose
pep257 to flake8 (there are no tests written directly against the plugin
that I'm aware of):
http://bit.ly/1MXu9Yv
Nearly half of pep257's codebase is actually tests. The tests, and code
are well written, well documented and easy to read, IMO.
Is the library python 3 compatible?
===================================
flake8_docstrings claims support for both Python 2 and 3.
pep257 claims support for Python 2.6, 2.7, 3.2, 3.3, 3.4, pypy and
pypy3.
Is the library license compatible?
==================================
flake8_docstrings LICENSE is MIT:
http://bit.ly/1MXuaM2
pep257 LICENSE is MIT:
https://github.com/GreenSteam/pep257/blob/master/LICENSE-MIT
Is the library already packaged in the distros we target?
=========================================================
I don't believe either is packaged for Ubuntu or Fedora.
Is the function of this library already covered by other libraries?
===================================================================
All of openstack/hacking's docstrings checks (hacking.checks.docstrings)
are redundant with pep257 standards and can potentially be deprecated in
favor of the more comprehensive coverage provided by pep257. Further, I
don't believe any of hacking's checks assert any direct conflicts with
pep257 (I've written a file that exercises all of pep257's checks and it
passes against hacking as well).
Change-Id: I60adf0dca4aa32f4ef6bca61250b375c8a3703c6
Related-Bug: 1501544
reno is a new tool for managing release notes using text files inside
the repository. We will need to add it to the test-requirements.txt file
so the sphinx integration can be used to publish release notes in the
development documentation builds.
Change-Id: Ibb2a08e9513123486ca58188ec097b7cd00c0d7f