Re: [PATCH 1/5] python: add pytest and tests

From: John Snow <jsnow@redhat.com>
To: Thomas Huth <thuth@redhat.com>, qemu-devel@nongnu.org
Cc: "Fam Zheng" <fam@euphon.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH 1/5] python: add pytest and tests
Date: Wed, 28 Oct 2020 14:38:04 -0400	[thread overview]
Message-ID: <46f7ec6b-0e15-f311-2890-635df64d4200@redhat.com> (raw)
In-Reply-To: <b412ee07-d274-4e0d-bb1c-81b53653cbb2@redhat.com>

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 <jsnow@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