pylint raises error if directory doesn't contain __init__.py file

$ 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)]

Update

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 |
+=========+=======+===========+===========+============+=========+
...

Error

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