Detect package when analysing import statements

[lfurrer]

In parallel to an issue over at AtomLinter, SublimeLinter-pylint produces spurious error messages when analysing dotted relative import statements inside a Python package.

For example, consider the following package (directory) structure:

working directory
| - package
|   | - foo
|   |   | - bar.py
|   |   | - baz.py

In the module bar.py, it's totally fine (AFAIK) to write:

from . import baz

However, if you simply run

pylint package/foo/bar.py

it will show an error "Attempted relative import beyond top-level package", because it doesn't recognize bar.py is part of a package.
This is also what I see in the editor when SublimeLinter-pylint is enabled.

In order for pylint to acknowledge the package structure, you have to run

pylint package.foo.bar

Is there any way for SublimeLinter to detect packages and adjust the calls to pylint accordingly?
Or is there at least a way to tell SublimeLinter-pylint where the package root is?

Please note: This is all Python 3.

[NotSqrt]

Hi,

There's a very useful setting paths that may help.

One of the reasons behind relative import errors is that the "background" lint mode of sublime linter uses a tmp copy of the file when linting your changes before saving the file. If you save the changes, the real file is used, resulting in different errors.

[lfurrer]

Hi,

thanks for the hint. This is {"SublimeLinter": {"linters": {"pylint": {"paths": []}}}}, right?
Is it used like the PYTHONPATH env var, ie. should it contain the parent directory of a package used?

I'm aware of the tmp copy effect: the error changes to "Cannot import" while there are unsaved changes.
The issue described here applies to "saved state".

I narrowed the problem further down: SublimeLinter-pylint correctly recognises "regular packages", even without explicitly listing them in paths. The problem only occurs with the so-called "namespace packages", a relatively recent feature (well, Python 3.3...). In namespace packages, there are no __init__.py modules, so basically any directory tree with .py files in it can be a package now. So, correctly recognising them might become a bit brittle...

[braver]

I think this is mostly a duplicate of #16.

[lfurrer]

As far as I understand #16, it turned out that the error only appeared when the file was unsaved. The error here only appears when the file is saved. And the error in #16 was "No name X in module Y", while here it is "Attempted relative import beyond top-level package".

[braver]

Part of me thinks we should just make this plugin file-only. It's much more powerful when running on the actual file, it's just not a good match for the tempfile approach. @kaste what about you?

[kaste]

I'm not a fan of pylint. It's super slow and not even correct.

[braver]

I don’t disagree. I’ll make it file-only so it’s consistent.

[lfurrer]

I hate to insist, but the behaviour described here ("Attempted relative import beyond top-level package" for namespace packages, ie. those without an __init__.py file) appears when the file is saved, ie. when pylint is run on the actual file, not the tempfile. I'm pretty sure #51 has no effect on the behaviour described here.

[braver]

Oh, good point. Well, someone who actually uses this and knows more about Pylint might be able to drum up a solution?

[kaste]

Hm, ’foo/init.py’ is missing in your first post.

(Backticks don't work on mobile.)