Make pylint work again

[VladimirSlavik]

Resolves:

• Running pylint standalone in container is possible
• New detections are all resolved
• Pylint runs among other ci tests, same as before

TODO:

• E0602(undefined-variable):ui/webui/test/check-basic:227,16: TestBasic.testJsErrorHandling: Undefined variable 'time'
• E1101(no-member):ui/webui/test/helpers/storage.py:414,8: StorageMountPointMapping.select_mountpoint: Instance of 'StorageMountPointMapping' has no 'set_partitioning' member
• Squash commits in make, it's easier to understand as one change

I'm rather stumped by the last two finds listed above, there's no clear reason how these actually work.

After this is done, we can make another PR where we either make pylint into another gh test alongside unit tests, or put it back with them as it was. I left out this part intentionally, so that we can have the fixes without the other decisions.

[vojtechtrefny]

* [ ]  `E1101(no-member):ui/webui/test/helpers/storage.py:414,8: StorageMountPointMapping.select_mountpoint: Instance of 'StorageMountPointMapping' has no 'set_partitioning' member `

I'm rather stumped by the last two finds listed above, there's no clear reason how these actually work.

StorageMountPointMapping doesn't have the set_partitioning function, but it never actually tries to call it, because StorageMountPointMapping isn't used directly, it is used only as a super class of Storage which also inherits from StorageScenario which is where set_partitioning lives so in the end Storage has access to both StorageMountPointMapping.select_mountpoint and StorageScenario.set_partitioning. Multiple inheritence is fun :-)
I'd recommend moving the select_mountpoint to a different class (probably StorageScenario) -- the function selects the mountpoint assignment scenario on the first storage screen so it doesn't really belong to StorageMountPointMapping anyway.

[pep8speaks]

Hello @VladimirSlavik! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file anaconda.py:

Line 72:100: E501 line too long (100 > 99 characters)
Line 153:100: E501 line too long (108 > 99 characters)

Comment last updated at 2024-02-22 08:32:46 UTC

[VladimirSlavik]

/kickstart-test --testtype smoke

[VladimirSlavik]

Looks like astroid dies on parsing subscription now. Can't reproduce locally. Lovely.

[jkonecny12]

Looks great to me. Thanks!

[jkonecny12]

Looks like astroid dies on parsing subscription now. Can't reproduce locally. Lovely.

I wonder if you don't have different version of a container image locally?

[VladimirSlavik]

That's a tricky question, as rebuilds are also stuck due to new dnf breaking tests...

Generally speaking, this can wait a bit.

[VladimirSlavik]

Still fails here and succeeds locally. I'll try filing the astroid bug implied by the results.

[VladimirSlavik]

Rebased. The failure persists. It seems I can reproduce that locally, sporadically: When I rebuild the CI container, the first test run in that container fails, sometimes. Re-running the tests will make them succeed. Rebuilding the container does not seem to negate the success on its own. So it's unpredictable anyway.

[KKoukiou]

Closing in favor of #5486 which has cherry-picked these commits. But at least we can stop spanning Vladimir's account.