From: John Snow <jsnow@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
qemu-block@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Max Reitz <mreitz@redhat.com>, Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH RFC 2/3] iotests: split 'linters.py' off from 297
Date: Mon, 7 Jun 2021 11:40:39 -0400 [thread overview]
Message-ID: <6bafcf85-07fe-e82c-1026-038c4b3f7f39@redhat.com> (raw)
In-Reply-To: <ba007a36-6e8f-29da-16a3-92f1599602c2@virtuozzo.com>
On 6/5/21 10:27 AM, Vladimir Sementsov-Ogievskiy wrote:
> 04.06.2021 19:39, John Snow wrote:
>> Refactor the core function of the linting configuration out of 297 and
>> into a new file called linters.py.
>>
>> Now, linters.py represents an invocation of the linting scripts that
>> more resembles a "normal" execution of pylint/mypy, like you'd expect to
>> use if 'qemu' was a bona-fide package you obtained from PyPI.
>>
>> 297, by contrast, now represents the iotests-specific configuration bits
>> you need to get it to function correctly as a part of iotests, and with
>> 'qemu' as a namespace package that isn't "installed" to the current
>> environment, but just lives elsewhere in our source tree.
>>
>> By doing this, we will able to run the same linting configuration from
>> the Python CI tests without calling iotest logging functions or messing
>> around with PYTHONPATH / MYPYPATH.
>>
>> iotest 297 continues to operate in a standalone fashion for now --
>> presumably, it's convenient for block maintainers and contributors to
>> run in this manner.
>>
>> See the following commit for how this is used from the Python
>> packaging side.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>>
>> ---
>>
>> - It's a big glob of a patch. Sorry. I can work it into smaller pieces
>> if the idea is well received.
>
> If at least split movement from other refactoring, would be good
>
Sure. Refactor first and then move seems like the way to go here. I'll
do that.
>>
>> - I change the invocations of mypy/pylint to "python3 -m pylint" and
>> "python3 -m mypy" respectively, which causes these linters to use the
>> virtual environment's preferred version. This forces the test to
>> use the
>> test environments curated by the CI jobs.
>>
>> - If you have installed Fedora's pylint package that provides
>> "pylint-3", the above trick will still work correctly.
>>
>> - Checking for "pylint-3" specifically in 297 was left
>> alone. Theoretically, this check could be broadened to simply look for
>> the presence of a 'pylint' module to allow it to be more permissive.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>> tests/qemu-iotests/297 | 88 ++++-------------------
>> tests/qemu-iotests/linters.py | 130 ++++++++++++++++++++++++++++++++++
>> 2 files changed, 143 insertions(+), 75 deletions(-)
>> create mode 100644 tests/qemu-iotests/linters.py
>>
>> diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
>> index 433b732336..5c753279fc 100755
>> --- a/tests/qemu-iotests/297
>> +++ b/tests/qemu-iotests/297
>> @@ -17,98 +17,36 @@
>> # along with this program. If not, see <http://www.gnu.org/licenses/>.
>> import os
>> -import re
>> import shutil
>
> [..]
>
>> - # fixed (in tests, at least)
>> env = os.environ.copy()
>> - qemu_module_path = os.path.join(os.path.dirname(__file__),
>> - '..', '..', 'python')
>> + qemu_module_path = os.path.join(
>> + os.path.dirname(__file__),
>> + '..', '..', 'python'
>> + )
>
> Hmm, you made 3 lines from 2 :) ... If rename to python_path it will fit
> into one line. I'm not sure that it's better.
>
I'll try it. I don't expect these args to change often so I don't insist
on the args-as-code-block thing here.
>> +
>> try:
>> env['PYTHONPATH'] += os.pathsep + qemu_module_path
>> except KeyError:
>> env['PYTHONPATH'] = qemu_module_path
>> - subprocess.run(('pylint-3', '--score=n', '--notes=FIXME,XXX',
>> *files),
>> - env=env, check=False)
>> - print('=== mypy ===')
>> - sys.stdout.flush()
>> -
>> - # We have to call mypy separately for each file. Otherwise, it
>> - # will interpret all given files as belonging together (i.e., they
>> - # may not both define the same classes, etc.; most notably, they
>> - # must not both define the __main__ module).
>> env['MYPYPATH'] = env['PYTHONPATH']
>> - for filename in files:
>> - p = subprocess.run(('mypy',
>> - '--warn-unused-configs',
>> - '--disallow-subclassing-any',
>> - '--disallow-any-generics',
>> - '--disallow-incomplete-defs',
>> - '--disallow-untyped-decorators',
>> - '--no-implicit-optional',
>> - '--warn-redundant-casts',
>> - '--warn-unused-ignores',
>> - '--no-implicit-reexport',
>> - '--namespace-packages',
>> - filename),
>> - env=env,
>> - check=False,
>> - stdout=subprocess.PIPE,
>> - stderr=subprocess.STDOUT,
>> - universal_newlines=True)
>> - if p.returncode != 0:
>> - print(p.stdout)
>> + for linter in ('pylint-3', 'mypy'):
>> + if shutil.which(linter) is None:
>> + iotests.notrun(f'{linter} not found')
>> + iotests.script_main(lambda: linters.run_linters(files, env=env))
>
> Why to use lambda, and not just pass main to script_main?
>
No strong reason, just a messy draft. I can clean it up as you suggest.
> Or, may be, use iotests.script_initialize() at top, and keep the whole
> script at top indentation level?
That works too, but it's more churn.
---
I need to look into the mypy invocation and see if I can't figure out a
way for it to work for everything at once instead of needing to run one
at a time. Maybe that's something to worry about later, though.
Eventually, the custom linter invocation here should be stored in more
traditional configuration files (pylintrc, mypy.ini) as much as is possible.
The environment hacking stuff will need to remain here as long as
iotests does not run in a virtual environment, however. I'd like to
eventually change that, too.
--js
next prev parent reply other threads:[~2021-06-07 15:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 16:39 [PATCH RFC 0/3] python/iotests: Run iotest linters during Python CI John Snow
2021-06-04 16:39 ` [PATCH RFC 1/3] python: expose typing information via PEP 561 John Snow
2021-06-04 16:39 ` [PATCH RFC 2/3] iotests: split 'linters.py' off from 297 John Snow
2021-06-05 14:27 ` Vladimir Sementsov-Ogievskiy
2021-06-07 15:40 ` John Snow [this message]
2021-06-04 16:39 ` [PATCH RFC 3/3] python: Add iotest linters to test suite John Snow
2021-06-05 14:08 ` [PATCH RFC 0/3] python/iotests: Run iotest linters during Python CI Vladimir Sementsov-Ogievskiy
2021-06-07 15:51 ` John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6bafcf85-07fe-e82c-1026-038c4b3f7f39@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).