Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python modules without __init__.py failed to be parsed since 2.5.0 #3528

Closed
nicocti opened this issue Apr 27, 2020 · 12 comments
Closed

Python modules without __init__.py failed to be parsed since 2.5.0 #3528

nicocti opened this issue Apr 27, 2020 · 12 comments

Comments

@nicocti
Copy link

nicocti commented Apr 27, 2020

Pylint 2.5 fails to parse modules without init.py while 2.4.4 works fine.
I found nothing in the changelog regarding this, so I guess it's a bug.

Steps to reproduce

  1. create a python module without init.py
  2. run pylint --disable=C,R ${MODULE_NAME}

Current behavior

raises:

************* Module ${MODULE_NAME}
${MODULE_NAME}/__init__.py:1:0: F0010: error while code parsing: Unable to load file ${MODULE_NAME}/__init__.py:
[Errno 2] No such file or directory: '${MODULE_NAME}/__init__.py' (parse-error)

Expected behavior

No error expected since init.py are optional since python 3.4+

pylint --version output

pylint==2.5.0
python==3.6.10

@Pierre-Sassoulas
Copy link
Member

I saw that but thought this was "normal" and the same than #352

@Pierre-Sassoulas Pierre-Sassoulas self-assigned this Apr 28, 2020
JJMC89 added a commit to jjmc89-bot/jjmc89-bot-scripts that referenced this issue Apr 29, 2020
JJMC89 added a commit to jjmc89-bot/jjmc89-bot-scripts that referenced this issue Apr 29, 2020
@Pierre-Sassoulas
Copy link
Member

I've done a git bisect on this. Seem like the culprit is a6d7ffc. I guess we don't want to revert it entirely? What do you think @PCManticore ?

@PCManticore
Copy link
Contributor

@Pierre-Sassoulas This is the exact same thing as #352. pylint never managed to analyze directories without __init__.py files.

I was able to reproduce it with the following version as well, which does not have the changes in the linked commit:

pylint 2.4.4
astroid 2.3.3
Python 3.8.1 (default, Feb 13 2020, 10:17:07)
[Clang 8.1.0 (clang-802.0.42)]

@nicocti Until we have a fix for #352, you'll need to either have a __init__.py in the directory that you are passing to pylint as an argument or you need to rely on shell expansion as in running pylint with pylint your_module/*.

@PCManticore PCManticore unpinned this issue May 2, 2020
@Pierre-Sassoulas
Copy link
Member

Strange, I tested by creating a directory called module with a test.py inside it and no init.py. Then, the test was:

pip3 install .;python3 pylint/__main__.py module

This was clearly working for 2.4.4 and until the commit which I linked, or am I missing something?

@PCManticore
Copy link
Contributor

No, you're right, for some reason my testing resulted in the same results on both versions.

@PCManticore PCManticore reopened this May 2, 2020
PCManticore added a commit that referenced this issue May 2, 2020
This was a regressin in 2.5.
Close #3528
@PCManticore
Copy link
Contributor

On second look, the fix turned out to be simpler than what I imagined. It's semantically the same with the old behaviour except sys.path is not modified.

PCManticore added a commit that referenced this issue May 2, 2020
This was a regressin in 2.5.
Close #3528
@nicocti
Copy link
Author

nicocti commented May 4, 2020

Thanks a lot for this quick fix :) Will keep you updated once I switch to 2.5.1 !

@jnsnow
Copy link
Contributor

jnsnow commented May 7, 2020

I think this caused a regression I am seeing; I was having no issues as of 2.4.4 nor 2.5.0:

layout:

qemu/
  lib/
    __init__.py
    qmp.py
    machine.py
    qtest.py

qtest.py has an import statement like this:

from .machine import QEMUMachine

If CWD is qemu/lib and I execute:
> pylint qtest.py

2.4.4:

Your code has been rated at 10.00/10 (previous run: 9.82/10, +0.18)

2.5.0:

Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

but 2.5.1:

qtest.py:24:0: E0402: Attempted relative import beyond top-level package (relative-beyond-top-level)

Current setup:

pylint 2.5.1
astroid 2.4.1
Python 3.7.7 (default, Mar 13 2020, 21:39:43) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]

If I install a dev copy of 4756b3c (origin/master as of writing) and revert this change, the explicit relative import works again.

@jnsnow
Copy link
Contributor

jnsnow commented May 8, 2020

From what I can tell, it seems as if the fact that I have an __init__.py is getting ignored (?), and my file is being processed as if it wasn't in a package.

@jnsnow
Copy link
Contributor

jnsnow commented May 13, 2020

@PCManticore sorry for the pester; should I port my reply here into a new issue?

@PCManticore
Copy link
Contributor

@jnsnow No worries. Yes, please open a new issue as it's more likely to get attention. Thank you!

@cl0ne
Copy link

cl0ne commented Nov 15, 2020

Note that you will get the same behavior as in the first message when you're linting some local implicit namespace package that (for whatever reason) has the same name as another regular package from sys.path. For example,

<some-other-path-from-sys.path>/xyz/
└── __init__.py
./xyz/
└── module.py

$ pylint --disable=C,R xyz
************* Module xyz
xyz/__init__.py:1:0: F0010: error while code parsing: Unable to load file xyz/__init__.py:
[Errno 2] No such file or directory: 'xyz/__init__.py' (parse-error)

At the same time it will run perfectly fine for

└── inner
    └── __init__.py
abcd
└── inner
    └── module.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants