Open abadger opened 5 years ago
This could be difficult to handle. I wonder if this might be something that could be fixed in pylint
itself.
Yeah, I opened up a bug report there, https://github.com/PyCQA/pylint/issues/2967 , but I don't know how quickly things get fixed in their project. In the past I had other import-related things that pylint handled better with module-name instead of file-name but I haven't seen those undder ALE... perhaps because ALE changes to the project root directory before running.
Information
VIM version
Also occurs with
Operating System: Fedora Linux 29
pylint-2.3.1
What went wrong
The pylint checker reports a False positive:
with code like the following:
when the toplevel is a PEP 420 implicit namespace package: https://www.python.org/dev/peps/pep-0420/
This is somewhat fragile in pylint itself as well.
However, if you run pylint on the module name instead of the filename, then it will detect the relative import correctly and will not find this false positive. (Examples in the reproducing section, below)
Reproducing the bug
hello-1.0.tar.gz
Line 1 is highlighted with a pylint error,
the same error should be seen if you do vim hello/level2/plugin1.py which has a slightly different relative path.
You can see this is a pylint limitation with filenames by doing:
You can see that there is a way to work around this pylint limitation by using a module name instead:
Based on the above, I wrote a short pylint wrapper which can work around this problem. However, it is not generic and possibly fragile. It is probably better if ALE provided a way to pass a function to transform the path that is given to the checker. ALE could give the function the project root and the path which will probably solve the genericity issue. I'm not sure whether the fragility issue can be perfectly remedied. The wrapper is here: https://gist.github.com/abadger/cd4d90552406290733a8f6fa8bdc0db4
:ALEInfo