On Fri, Aug 30, 2024 at 02:22:50PM -0400, John Snow wrote:
> Gave Dan a related answer. For you, my explanation is:
>
> - It's nice to have just one configuration for static analysis in just one
> place
> - It's nice to have that configuration follow python ecosystem norms
> - It's nice to use standard python management tools to configure and test
> the supported versions of static analysis tools, again kept in one place.
> - Just moving the folder costs virtually nothing.
> - Moving it here makes it easier for me to test the eventual integration
> with make check in one place.
> - I like being able to say that anything under `python/` is fiercely
> guarded by high standards (and the gitlab pipelines) and everything else is
> not. I consider this to be organizationally simple and easy to communicate.
> i.e., I find it attractive to say that "python is maintained, scripts are
> YMMV." I am *not* willing to maintain everything under `scripts/` with the
> same level of effort I apply to `python/`. I think it's important to allow
> people to commit low-development-cost scripts ("contrib quality") that they
> can run from time to time and not everything needs to be held to a
> crystalline perfect standard, but some stuff does.
FYI, I was NOT suggesting that you maintain anything under scripts/.
Rather I'm saying that if we want to apply python code standards, we
should (ultimately) apply them to all python code in the tree, and
that *ALL* maintainers and contributors should comply.
Right, it's just that the level of care to bring everything up to that standard is currently more effort than I'd like to spend.
Ideally everything WOULD be on the same standard, but...
Consider our C standards - we don't apply them selectively to a subset
of the tree - we expect all maintainers to comply. I'd like us to have
the same be true of Python.
The only real issue we have with python standards is bringing existing
code upto par, before we can enable the checks.
Yeah, exactly. It took me long enough to do this with qmp, machine, qom and qapi. It'll take aeons for iotests.
It's just not on my radar right now as a priority.
More tractable: protect everything used for the build to that high standard, worry about the rest later.
Currently we have no easy way for other maintainers to enable their
python code be checked, without moving their code under python/ which
is undesirable IMHO.
It's possible I can extend a "lower standard" to everything outside of python/ to help enforce the basics, without mandatory typing.
(I did add an iotest checker to python/ tests that enforces a lower standard to those tests. I intend to remove iotests 297 once I get a top-level "make check-python" instituted.)
I don't think one unified standard is something we can do in the near term. Mechanically I think it's easy, but in practice pushing all the linting patches through has been like pulling teeth and I've lost appetite for pursuing it beyond whatever is *super duper important*.
In retrospect, 3.6 was too early to try adding static typing. I think I won't bother for anything else until we have 3.9 as a minimum. After the pushback last time, I doubt I'll make the push any time soon unless something really urgent comes up.
If we move the python coding standards to meson.build, such that apply
to all of the source tree, and then exclude everything except python/,
we make it easier for other maintainers to bring stuff upto par. All
need do at that point is remove the exclusion rule for files incrementally
as they fix them.
Not against this in the future, I just think there are some higher priority items to take care of first:
* Begin protecting qapi with the existing python static analysis regime
* Add a "make check-python" target to the top level makefile that can set up the environment it needs on-demand and handles what python/'s "make check-minreqs" currently does (incl iotest 297)
* Drop python/qemu/qmp from the tree in favor of the standalone package. There are mkvenv changes I'm currently developing here to make this happen. It's a little involved due to the wide spread of setuptools versions on platforms we support.
Once I drill through these, I'm more than happy to try to support/maintain everything else to a lower baseline of care. Maybe this winter, if you'd be willing to volunteer some review time for the push.