Commit Graph

32 Commits

Author SHA1 Message Date
Stephen Finucane a5c99fddbf Alphabetise blacklist
Change-Id: I037d15a20cb2f84424c5525bf5afb63b128ba785
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2024-01-18 09:05:12 +00:00
Stephen Finucane b353fd3084 Move mypy to blacklist
mypy is a linter, not something that is used at runtime. Move it to the
blacklist.

This also reverts commit 2bbbdb9991 as a
cross-project job no longer makes sense with the newly blacklisted
dependency.

Change-Id: Iaf6d2c4aed92f35240b393939bbf76fd7d5d9aa2
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2024-01-18 12:19:22 +11:00
Stephen Finucane d497b2379e Move bashate to blacklist
bashate is a linter. Like other linters, it should not be tracked in
upper-constraints.

Change-Id: Ic2783f01bc123ef99d9499451b85ad2286a850ad
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2022-08-05 12:47:23 +01:00
Dmitriy Rabotyagov a420f293d6 Do not fix certifi version
It's not safe to constraint certifi since we need to use latest
CA certificates anytime and not force deployments to use outdated CA
files.

This is inspured with latest Let's Encrypt Root CA rotation, since older
deployments can't reach even opendev because of outdated certifi.

Change-Id: I3eeab01ccb758cf4eeebcb5da8bf0aea1ff77a88
2021-10-26 09:50:47 +00:00
Jiri Podivin 99881be36e Adding ansible-core to the blacklist
Ansible core is going to take the role of ansible in some projects,
as the dependencies move to the ansible>2.10.

Right now that's the case only for VF, but more might come in
the future and it's best to be ready.

The inclusion of the ansible-core on the blacklist would serve
exactly the same purpose as the inclusion of original ansible package.

Signed-off-by: Jiri Podivin <jpodivin@redhat.com>
Change-Id: I36331013568a36c963c180db10e30c3b72cf86a8
2021-09-06 14:06:44 +02:00
Matthew Thode 07817aec22
add pkg_resources to blacklist
Change-Id: Idbcba5b11928ef404db2021fd60d43998c3d1b81
Signed-off-by: Matthew Thode <mthode@mthode.org>
2021-08-06 10:42:23 -05:00
Ghanshyam Mann 4c3828350c Move tempest to blacklist
Tempest and its plugins are branchless which means master version
of these tools are used in testing the master + stable branches
(except EM stable branch where we pin the Tempest and plugins for testing).
Keeping Tempest in the u-c file will block testing the master + stable branches
with Tempest master. Bug#1916771 for more details.

Once any stable branch move to 'Extended Maintenance' and we pin the
older Tempest to test them then we can move it from here to u-c file.

Related Bug: #1916771

Change-Id: I891f5e1f4393c832f8f9feb6094fb9d8cc5dba35
2021-08-03 10:13:44 -05:00
Akihiro Motoki 7bafda3dca Drop horizon from blacklist
horizon switched the release model to cycle-with-intermediary
in Ussuri release so that horizon works as a library for horizon plugins.
I think we can drop horizon from the blacklist.

Change-Id: I958ff99870eccef9b264904599971c7884d9bb6f
2021-01-15 07:19:33 +00:00
Rodolfo Alonso Hernandez be1dca06e0 Add "isort" library to blacklist
"pylint" requires a class named "SortImports", not present in
"isort" versions >=5.0.0. Until "pylint" fixes this problem, we
should allow each projecty to install its own "isort" library
version to unblock CI pep8 jobs.

Change-Id: I158bcc8c249ad7ec981707c0d96ad8db87eb23d9
Related-Bug: #1886422
2020-07-07 09:51:56 +00:00
Michal Nasiadka 6ca51f2b1c Add yamllint to blacklist
Some projects, such as kolla-ansible, use yamllint for linting YAML
code.
At present it is not possible to add this to your requirements as it
does not appear in the global requirements file.

Change-Id: Ibf26d927cd45d0f39a0fcb7c4700786dbf002459
2020-05-14 12:31:42 +02:00
Will Szumski dcef447f6d Add ansible to blacklist
Some projects, such as kolla-ansible, have a dependency on ansible. At
present it is not possible to add this to your requirements as it does
not appear in the global requirements file. However, it is useful to
have ansible as dependency to allow testing of plugins.

There is not a strong dependence on the openstack libraries, so it makes
sense to include this in the blacklist and not in global requirements,
so that the individual projects can specify the version required.

Change-Id: Ie30fe79e686f89fbdb246b5330d5b9f10aecf354
2020-05-11 10:52:27 +01:00
Jesse Pretorius (odyssey4me) 72c5ac955c Add Pygments to upper-constraints
Pygments is already in global-requirements, but not in
upper-constraints. Pygments is required by Sphinx.

Pygments removed support for py2 in version 2.6.0 so we
need to ensure that it is properly pinned to prevent
tests/docs failing.

Pygments was added to the blacklist in
I643c7632a02c87820c9c51f03fa34f0764384783 but it's not
entirely clear why. To ensure that it is managed in
upper-constraints from now on, we remove it from the
blacklist.

Change-Id: I18a50482e588176047ede81c4ee994c9d7df282b
Closes-Bug: #1869174
2020-03-26 13:06:54 +00:00
Sean McGinnis d36ea16c31
Add flake8-logging-format linter to blacklist
Change-Id: Id2ebe8f1b9bb7a0b6b096d874d8737b154887e60
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2019-12-19 10:39:35 -06:00
Dmitriy Rabotyagov 24db3f8953 Adds ansible-lint to the blacklist
Avoids check-requirements failure regarding usage of ansible-lint.

Needed-By: https://review.opendev.org/679101
Needed-By: https://review.opendev.org/679105
Change-Id: I36602e2f4ca1542b6c60df1ae9fcdc551451a3e0
2019-08-29 15:38:18 +03:00
Luigi Toscano 9702f0d482 Make sahara (now core only) usable as requirement
Starting from Stein, sahara.git contains only the core (services and base
classes) of Sahara. The code of plugin was moved into its own repository.
Each plugin depends on Sahara core, so in order to use it as dependency
it must be added as requirement somehow.
No additional splits are planned right now, which means no sahara-lib,
which means adding sahara to blacklist.txt

* Is the library actively maintained?
  Yes

* Is the library good code?
  Yes, it is has been part of OpenStack for few years

* Is the library python 3 compatible?
  Yes

* Is the library license compatible?
  Yes,Apache 2

* Is the library already packaged in the distros we target (Ubuntu latest /
  Fedora latest)?
  It will be as part of the sahara release

* 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? (Answer to this should be Yes, of course) Which?
  Yes, Sahara

* If the library release is managed by the Openstack release process does it use
  the cycle-with-intermediary release type?
  Right now it uses cycle-with-rc, which still allows for intermediate releases

Change-Id: Ia8f2ccfb01492c109fe7d2810f6b441d644c2572
2019-01-22 17:06:23 +01:00
Sorin Sbarnea 13abf68ae7 Adds pre-commit linter to the blacklist
Avoids check-requirements failure on projects using pre-commit, like
tripleo ones.

Change-Id: Idc1e76e178e63cc0efa5279f779a18dac18a1bc7
2018-12-18 20:34:38 +00:00
Andreas Jaeger aef0c3ae83 Update comment in blacklist for networking repos
As https://review.openstack.org/#/c/553240/ has shown, adding
upper-constraints for these repos does not work, we can only use the
versions from the previous release and those versions conflict with
other packages from current release. Therefore leave them - unlike
previously planned - in blacklist.txt and update the comment to reflect
this.

Change-Id: I3bbf28720b8ae7752df0ae56de2d42451cf52296
2018-07-20 08:42:27 +02:00
Nguyen Van Trung aee6e95380 Allow Pygments in openstack/requirements
Projects that want to enable a comprehensive doc8 check of code,
including D000, need Pygmnets to be installable.  It's an option library
used by docutils so we need to track it here.

While this isn't really a linter, neither is it really required at
runtime for the projects using it so it's added to the blacklist

Is the library actively maintained?
Yes - https://bitbucket.org/birkenfeld/pygments-main

Is the library good code?
Yes - It is the defacto syntax highlighting code in Python

Is the library python 3 compatible?
Yes

Is the library license compatible?
Yes - BSD

Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
Yes

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? (Answer to this should be Yes, of course) Which?
Yes - for doc8 checking where there is code snippets.
It is also a transient dependancy of sphinx - https://github.com/sphinx-doc/sphinx/blob/master/setup.py#L21

Change-Id: I643c7632a02c87820c9c51f03fa34f0764384783
Close-bug: #1771479
2018-05-17 14:00:54 +07:00
Andreas Jaeger 479d010d2d Add some OpenStack networking-* projects to global-requirements 1/2
Now that we're publishing them to PyPI we can begin the work of
reworking the plugin projects to depend on the PyPI versions instead
of listing direct git url depends. To do that, we need them in
global-requirements.

Add networking-odl, networking-bagpipe, networking-bgpvpn,
networking-sfc, networking-l2gw, neutron-lbaas, neutron-fwaas,
neutron-vpnaas, neutron-dynamic-routing, and vmware-nsxlib.

Add these only to global-requirements for now - that way
tools/tox_install.sh continues to work. As next step we can migrate from
tox_install.sh to requirements and then add the constraints.

Change-Id: I9feeda89b87bd88636170fee25dc6d1c20208e37
2018-03-19 17:52:10 +01:00
Andreas Jaeger 29ce972ab2 Add neutron/horizon to blacklist
Having neutron/horizon in constraints breaks all tools/tox_install.sh.

While we work on fixing them, remove the constraints.

We can revert this change later.

Change-Id: I7b8f2be1061dafa3d90674e3160650a3e967c219
2018-03-14 20:56:07 +01:00
Dirk Mueller 1a9a31d361 Add pycodestyle
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
2017-11-14 23:55:27 +01:00
Dirk Mueller 4f54188c61 Normalize global-requirements.txt
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
2017-11-02 00:58:04 +00:00
Dirk Mueller 7f98be6ded Move bandit into the linters blacklist
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
2017-10-24 18:05:52 +02:00
Akihiro Motoki c813397b6f Remove astroid from global-requirements list
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
2017-07-05 12:34:18 +00:00
Masayuki Igawa 53e13b08f1
Add flake8-import-order to global-requirements.txt
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
2017-02-14 12:48:27 +09:00
Doug Hellmann 0c6488e38e remove reno from the blacklist
Go ahead and manage reno like our other dependencies.

Change-Id: I496adf3df5ff3d349f96c81da6ec8221595b6fa8
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2016-06-23 14:21:01 -04:00
YAMAMOTO Takashi 9c8d9039fb Fix typos in comments
Change-Id: I6b90a3d831704fe40862dcf8421c4ffdbbeab7f7
2015-12-03 16:30:42 +09:00
Jenkins 2854532c85 Merge "Document the blacklist intent for reviewers." 2015-10-24 02:05:52 +00:00
Robert Collins 7eab32a33b Document the blacklist intent for reviewers.
Change-Id: If99e6997b11e50758a9041cacbc4f4c7938cb11f
2015-10-20 10:52:27 +13:00
Dolph Mathews 5b6a051b3e Add pep257 as a requirement
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
2015-10-15 17:20:16 +00:00
Doug Hellmann fed1805227 Add reno for release notes
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
2015-09-22 21:20:41 +00:00
Robert Collins 5cd10eb1f6 Teach the constraints generator about excludes.
Some things like flake8 can't be constrained, so we need an opt-out
clause.

Change-Id: I11eb0d762869ad8920795fb710f1b2eeb9354f12
2015-06-24 09:42:52 +12:00