another pylint error mis-match

[praiskup]

================
 Fixed warnings 
================

Error: PYLINT_WARNING:
coprs_frontend/tests/test_logic/test_modules_logic.py:106:8: W0632(unbalanced-tuple-unpacking): TestModuleBuildFacade.test_add_builds_batches: Possible unbalanced tuple unpacking with sequence defined at line 23: left side has 3 label(s), right side has 2 value(s)

================
 Added warnings 
================

Error: PYLINT_WARNING:
coprs_frontend/tests/coprs_test_case.py:547:8: W0201(attribute-defined-outside-init): CoprsTestCase.f_modules: Attribute 'm4' defined outside __init__

Error: PYLINT_WARNING:
coprs_frontend/tests/test_logic/test_modules_logic.py:126:8: W0632(unbalanced-tuple-unpacking): TestModuleBuildFacade.test_add_builds_batches: Possible unbalanced tuple unpacking with sequence defined at line 25: left side has 3 label(s), right side has 2 value(s)

https://jenkins-fedora-infra.apps.ci.centos.org/job/copr/125/console

[praiskup]

Another a bit more complicated :-(
https://jenkins-fedora-infra.apps.ci.centos.org/job/copr/114/console

Error: PYLINT_WARNING:
coprs_frontend/tests/test_logic/test_builds_logic.py:1: R0801(duplicate-code): Similar lines in 2 files
==coprs.views.apiv3_ns.apiv3_builds:202
==coprs.views.coprs_ns.coprs_builds:213
            flask.g.user,
            copr,
            form.pypi_package_name.data,
            form.pypi_package_version.data,
            form.spec_template.data,
            form.python_versions.data,
            form.selected_chroots,

[kdudka]

I am not sure what to do with these reports. They should ideally be split into an error/warning event that uniquely describes the problem, followed by a series of notes that describe the context (but that are ignored by the matching algorithms in tools like csdiff). I am afraid that, if we manually implement messages filters in csdiff for all such reports, it is not going to scale in long term.

[praiskup]

it is not going to scale in long term

Since we plan to use the linter it's somewhat important to have the
filters somewhere. Perhaps it is time to start thinking about moving the
filters to copr code?

Perhaps I could try to have a look at pylint's basecode whether there
isn't some list of patterns which we could compile into filters
(semi-)automatically?

[praiskup]

Since we plan to use the linter it's somewhat important to have the
filters somewhere. Perhaps it is time to start thinking about moving the
filters to copr code?

Instead of concentrating on csdiff here we should concentrate on
making the code cleaner ...

Perhaps I could try to have a look at pylint's basecode whether there
isn't some list of patterns which we could compile into filters
(semi-)automatically?

Nothing obvious. I'll try to play with the line\s\d+ pattern, later.

[kdudka]

If maintaining such filters somewhere was the only option, then I would prefer to have them in csdiff (instead of copr), to make them at least reusable across other similar upstream CI systems. It would be much better if pylint developers had machine processing in mind while constructing new diagnostic messages in their checkers. But I do not have free capacity to fight for it myself...

[praiskup]

If maintaining such filters somewhere was the only option,

There are three options, (a) ignore the not-matched warnings, (b) fix them
(even though fixing irrelevant pylint warnings makes pull requests ugly)
or (c) fix csdiff (add the filter).

then I would prefer to have them in csdiff (instead of copr),

Maybe we could implement new option --event-filters-file FILE, taking files
like:

PYLINT_WARNING|PROSPECTOR_WARNING   # matching checkers
s|reg|exp|                          # the event filter
                                    # separator
PYLINT_WARNING                      # ...
...

Having something like that, we could quickly provide new filters and then
from time to time backport them back to "upstream" csdiff code.

[praiskup]

It would be much better if pylint developers had machine processing in
mind while constructing new diagnostic messages in their checkers. But
I do not have free capacity to fight for it myself...

Agree that would be awesome, but I'm afraid I neither have the capacity
to manage that (long shot). Honestly, I don't even want to ... the
status quo is already pretty tolerable for the use-case we have.

[kdudka]

Is recompilation of csdiff really the bottleneck here? How frequently are you going to change the file with filter definitions?

As for the filter definition file format, I would prefer JSON because it is already used by csdiff.

[praiskup]

Is recompilation of csdiff really the bottleneck here?

The contribution to C++ source is somewhat bottlenecking. Our team isn't
generally aware of that language. It would be awesome if even csdiff
itself shifted the list of filters to some easy-to-read configuration file.

How frequently are you going to change the file with filter definitions?

I don't know, hopefully we'll iterate to fixed set of filters fast ... but I already
seem to make you tired about pylint, and it's definitely not a good sign.

I would prefer JSON

+1

[kdudka]

No worries, I was just busy ;-) Issue #11 has been created to track the progress on this.