Enable pylint checks #4092
Enable pylint checks #4092
Conversation
@skshetry The problem is that we will forget about them if we don't do it right away. Disabling everything doesn't make any sense, we will miss new features and will never enable them. |
|
@efiop, No, I will keep making any PRs until we enable the checks that we need. I'd not suggest enabling everything and blacklisting some, at least for now. Let's go the other way round. |
So you plan on going through all avaliable checks one-by-one? What if there will be new features in the future? Or do you plan on starting with this and then switch this the other way around and enable everything and disable some? |
|
@efiop, for the start, I'd love to keep things sane with pylint, and keep a whitelisted list of checks. Otherwise, we would just keep fighting over I'd recommend starting small and postpone the switching decisions for later. |
|
@skshetry We will have to enable everything and blacklist some in the near future, otherwise we will not even know that there is something useful (e.g. new) we can whitelist. I'm fine with starting with the current approach only if we switch in the near future. |
| - name: Install requirements | ||
| run: bash ./scripts/ci/install.sh |
There was a problem hiding this comment.
pylint requires all of the dependencies installed to check for import-error. Could either disable it (which is bad) or, need to install all of the dependency before-hand.
| - repo: local | ||
| hooks: | ||
| - id: pylint | ||
| name: pylint | ||
| entry: pylint | ||
| language: system | ||
| types: [python] |
There was a problem hiding this comment.
pre-commit creates an isolated virtualenv. But, for dynamic analysis such as import-error, pylint requires certain sets of dependencies installed, hence we need to use system's python (eg: from pip-installed one).
|
@efiop, I think we need to at least keep |
|
@efiop, also I think we could start with this PR. I will follow-up with some PRs tomorrow. |
There was a problem hiding this comment.
I agree with @efiop that, in the end, we should enable all checks that are not explicitly forbidden, but if we don't want to end up with single PR containing all fixes, which will be hard to merge, we should iterate gradually over whitelist until we can make the switch. In that case, we should probably reopen #219 and assign someone until the transition is done.
| jobs: | ||
| build: | ||
|
|
||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
To avoid unpredictible behavior, maybe we should stick to particular version? like 18.04/20.04?
There was a problem hiding this comment.
I think it's okay to use the latest one. If it breaks, we will know.
It was getting ugly, so I decided to disable every checks and start enabling one-by-one that is preferred by us.
If there's no consensus among us to enable particular checks, we should keep it disabled.
Deepsource will be affected by this change (and, might return less error while in transition).
❗ I have followed the Contributing to DVC checklist.
📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.
❌ I will check DeepSource, CodeClimate, and other sanity checks below. (We consider them recommendatory and don't expect everything to be addressed. Please fix things that actually improve code or fix bugs.)
Thank you for the contribution - we'll try to review it as soon as possible. 🙏