I have the folder that contains only python scripts for execution. It's not necessary to keep __init__.py
file. So can I ignore such error?
$ pylint /app
Using config file /app/pylintrc
*************
F: 1, 0: error while code parsing: Unable to load file /app/__init__.py:
[Errno 2] No such file or directory: '/app/__init__.py' (parse-error)
$ sw_vers ProductName: Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G65 $ pylint --version pylint 2.1.1 astroid 2.0.3 Python 3.7.0 (default, Jul 23 2018, 20:22:55) [Clang 9.1.0 (clang-902.0.39.2)]
I got this to work by trying:
$ cd /app $ pylint *.py
or try:
$ pylint /path/to/app/*.py
and got the whole thing working.
... Report ====== ************* Module <yourmodname> ... X statements analysed. Statistics by type ------------------ +---------+-------+-----------+-----------+------------+---------+ |type |number |old number |difference |%documented |%badname | +=========+=======+===========+===========+============+=========+ ...
I had tried to do:
$ pylint . ************* Module . __init__.py:1:0: F0010: error while code parsing: Unable to load file __init__.py: [Errno 2] No such file or directory: '__init__.py' (parse-error)
This is a known open issue of PyLint:
lint all files in a directory (open)
Consider supporting a folder of python files which is not a package (duplicate, closed)
Unfortunately, as we can see in the discussion, no one continued working on it.
This issue appeared in some projects of ours.
In one of these projects, we had a very recent successful build, but suddenly everything started to fail with no reason. We went to our CI logs to the last successful build, copied the exact version of everything installed. When building that way, everything worked. New versions would fail.
The successful build on this project was from 23.02.2019 and the failing one from 25.02.2019. No substantial changes introduced. Running with the same state as before, failure again...
A couple more hours were invested into this and we found:
while debugging, other errors started to happen. It turns out that astroid
released version 2.2.0 in 27.02.2019 and this basically broke pylint
. Pinning astroid
back to version 2.1.0 solves this problem. We'll keep it like this until they release a patch or pylint
starts to deal with the new version. There's an issue on Github about this.
with the astroid
problem addressed, we got back to the failures due to the lack of __init__.py
files in some directories (these are Python 3.7 projects and we don't need empty __init__.py
files...)
several attempts were done to find why the old combination worked and the new one didn't. After a lot of failing builds, we found that a PATCH update of another dependency of pylint
-- isort
-- from 4.3.4 to 4.3.5, released in 25.02.2019, introduced the bug. Pinning it back to version 4.3.4 worked just fine. Anything above it fails. Honestly, that update didn't follow the rules of semantic versioning (it's definitely NOT a patch release... It's more likely a MAJOR!).
Why exactly isort
is causing this, I couldn't find yet, but I decided to share these findings here, so you can save several hours of trial & error.
TL;DR:
Add this to your requirements.txt
(at least until the next release of pylint
):
# astroid 2.2.0 seems to break everything in pylint
astroid==2.1.0
# isort above 4.3.4 introduces the "__init__.py not found" issue
isort==4.3.4
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With