[CI Problem] PyLint version update causing new `ci_lint` image to report many linting issues

[lhutton1]

Recently the version of PyLint was updated from 2.4.4 to 2.9.3 (#11734), however, in doing so usage of the new ci_lint image are failing with a bunch of linting complaints e.g. https://ci.tlcpack.ai/blue/organizations/jenkins/docker-images-ci%2Fdocker-image-run-tests/detail/docker-image-run-tests/146/pipeline.

While this is not a problem in TVM's CI since the images need updating manually (for now, until #11768), it renders using a newly built ci_lint unusable due to the linting complaints. One solution would be to go through and fix all of these complaints. Although, since there are quite a few (~500) it may take some time to get the codebase upto the standard of the new PyLint version. Therefore, I suggest we revert the commit #11734 for now so that a newly built ci_lint image can be used by anyone wishing to do so. Then, submit a new patch with the version change and the relevant complaints fixed at a later date. Wondering what other people's thoughts are on this?

cc @leandron @manupa-arm @areusch @AndrewZhaoLuo @junrushao1994 @ashutosh-arm @driazati

[manupak]

I think you mean #11734 ? :)

I think landing the docker change early leaves the codebase in a in-consistent state, especially where the the follow-up change is not trivial. As a policy, we should think of a way to reduce the gap (ideally there should not be a gap but that will only happen with #11768)

Is there an urgency of landing #11734 ? (especially, if the next one is not ready at the same time). Eitherway, we should only be landing the former when the latter is ready, especially in pylint upgrades where the fixes are non-trivial. However, this policy is tricky to be implemented.

If not we can just wait until #11768 that removes this two PR based flow of updating docker.

My suggestion is to :

• revert [Docker][Pylint] Upgrade ci lint docker file #11734 for now
• wait until work is done on [docker] Implement Docker image automated updates #11768
• then re-do [Docker][Pylint] Upgrade ci lint docker file #11734 with actual changes that is required to do the update.

[lhutton1]

I think you mean #11734 ? :)

Oops! Fixed, thanks

[leandron]

To speed up the fixing, I've created #11787 so that the revert can run CI and we can hopefully merge it soon.

[driazati]

If not we can just wait until #11768 that removes this two PR based flow of updating docker.

just fyi #11768 doesn't actually do this, it just automates some of the pain away (image bumps are still manual but a bot will file the PR instead of a person, CI will update/tag images in Docker Hub as they come along) and should hopefully catch issues like this by running CI with the new images on PRs where docker/* files are changed. We decided against using newly built images every time in as in #11673 since external dependencies could then break CI at any time rather than be gated behind an update

[lhutton1]

Revert in #11787 has been merged so closing this issue