On 10/28/20 10:54 AM, Thomas Huth wrote:
On 28/10/2020 14.23, John Snow wrote:
On 10/28/20 2:19 AM, Thomas Huth wrote:
On 27/10/2020 23.38, John Snow wrote:
Try using pytest to manage our various tests; even though right now
they're only invoking binaries and not really running any python-native
code.
Create tests/, and add test_lint.py which calls out to mypy, flake8,
pylint and isort to enforce the standards in this directory.
Add pytest to the setup.cfg development dependencies; add a pytest
configuration section as well; run it in verbose mode.
Finally, add pytest to the Pipfile environment and lock the new
dependencies. (Note, this also updates an unrelated dependency; but the
only way to avoid this is to pin that dependency at a lower version --
which there is no reason to do at present.)
Provided you have the right development dependencies (mypy, flake8,
isort, pylint, and now pytest) You should be able to run "pytest" from
the python folder to run all of these linters with the correct
arguments.
Signed-off-by: John Snow <js...@redhat.com>
---
python/Pipfile.lock | 71 ++++++++++++++++++++++++++++++++++++---
python/setup.cfg | 5 +++
python/tests/test_lint.py | 28 +++++++++++++++
3 files changed, 99 insertions(+), 5 deletions(-)
create mode 100644 python/tests/test_lint.py
diff --git a/python/Pipfile.lock b/python/Pipfile.lock
index 05077475d750..105ffbc09a8e 100644
--- a/python/Pipfile.lock
+++ b/python/Pipfile.lock
@@ -30,6 +30,14 @@
"markers": "python_version >= '3.5'",
"version": "==2.4.2"
},
+ "attrs": {
+ "hashes": [
+
"sha256:26b54ddbbb9ee1d34d5d3668dd37d6cf74990ab23c828c2888dccdceee395594",
+
"sha256:fce7fc47dfc976152e82d53ff92fa0407700c21acd20886a13777a0d20e655dc"
+ ],
+ "markers": "python_version >= '2.7' and python_version not
in '3.0, 3.1, 3.2, 3.3'",
Can't you simply use "python_version >= '3.6'" instead?
Thomas
This file is generated; I don't really actually know what these markers mean
or to whom. I can't edit it because it's checksummed.
If the file is only generated, why do we need that in the repository? ...
that only calls for trouble if other people try to apply changes here...
Because it is generated with respect to a given point in time; this
specifies the exact loadout of packages that will be used to run the linter.
If you remove it, every time you run "pipenv lock" again, it will use
newer and newer packages each time ... which defeats the purpose of
having a lockfile to begin wtih.
The intention is that this lockfile only gets updated as an intentional
action; using newer dependencies and so on for the test environment is a
conscious action.
You are free to use the latest and greatest packages yourself if you
choose; just skip the venv step -- but then you're on your own for
making sure that environment works. *this* environment receives my
full-throated support. The tests will and must pass on *this* environment.
--js
