On 22.09.21 22:38, John Snow wrote:
On Wed, Sep 22, 2021 at 4:37 PM John Snow <js...@redhat.com
<mailto:js...@redhat.com>> wrote:
On Fri, Sep 17, 2021 at 7:16 AM Hanna Reitz <hre...@redhat.com
<mailto:hre...@redhat.com>> wrote:
Question is, when “can we use” mypy >= 0.920? Should we check the
version string and append this switch as required?
The answer to that question depends on how the block maintainers
feel about what environments they expect this test to be runnable
under. I lightly teased kwolf once about an "ancient" version of
pylint they were running, but felt kind of bad about it in
retrospect: the tests I write should "just work" for everyone
without them needing to really know anything about python or
setting up or managing their dependencies, environments, etc.
(1) We can use it the very moment it is released if you're OK with
running 'make check-dev' from the python/ directory. That script
sets up its own virtual environment and manages its own
dependencies. If I set a new minimum version, it will always use
it. (Same story for 'make check-tox', or 'make check-pipenv'. The
differences between the tests are primarily on what other
dependencies they have on your environment -- the details are
boring, see python/Makefile for further reading if desired.)
(2) Otherwise, it depends on how people feel about being able to
run this test directly from iotests and what versions of
mypy/pylint they are using. Fedora 33 for instance has
0.782-2.fc33 still, so I can't really "expect" people to have a
bleeding-edge version of mypy unless they went out of their way to
install one themselves. (pip3 install --user --upgrade mypy, by
the way.) Since people are used to running these python scripts
*outside* of a managed environment (using their OS packages
directly), I have largely made every effort to support versions as
old as I reasonably can -- to avoid disruption whenever I possibly
can.
So, basically, it kind of depends on if you want to keep 297 or
not. Keeping it implies some additional cost for the sake of
maximizing compatibility. If we ditch it, you can let the scripts
in ./python do their thing and set up their own environments to
run tests that should probably "just work" for everyone.297 could
even just be updated to a bash script that just hopped over to
./python and ran a special avocado command that ran /only/ the
iotest linters, if you wanted. I just felt that step #1 was to
change as little as possible, prove the new approach worked, and
then when folks were comfortable with it drop the old approach.
Oh, uh, and to answer your more concrete question: Nah, we don't need
to conditionally append this workaround. The speed lost from making
the check incremental is made up for by not invoking the tool 20
times, so it's OK to just unconditionally add it for now.
Well, yes, but it could be even faster!
And also it would save us from the pain of waiting and judging when it’s
reasonable to drop `--no-incremental`, and/or just forgetting that this
workaround even exists. If we checked the version string, it would be
OK to just forget about it, I think.
Hanna
