-
Notifications
You must be signed in to change notification settings - Fork 8
[BUG]Why does adding a module produce F6401 #21
[BUG]Why does adding a module produce F6401 #21
Comments
After debugging the source code, I found out that the cause of my problems was an error in My source code had a type annotation error that caused pytest to look for a fixture from that module that was wrong, and the error was passed to pylint. But why there is a different output is not clear to me. From debugging the source code, we know that pylint-pytest/pylint_pytest/checkers/fixture.py Lines 92 to 142 in 6267638
The pylint-pytest/pylint_pytest/checkers/fixture.py Lines 125 to 131 in 6267638
In pylint-pytest/pylint_pytest/checkers/fixture.py Lines 24 to 34 in 6267638
I don't think this logic makes sense. Pytest should only collect fixtures from the test modules, and instead of collecting fixtures from all modules, Pylint-Pytest should filter out the source code when PyLint checks. Hope to fix this problem. |
I'm seeing this today as well. Curious about this statement:
That makes sense to me, because I don't think I'd want to put fixtures in source code, but how would pylint (and subsequently pytest) know the difference between source and test code? |
Hi @miketheman In If aone source file is bad small, pytest will error.I had these problems because one of the methods in the source code had the wrong return value type. However, it should be indicated exactly by If we only talk about [tool:pytest]
testpaths = tests
python_files = tests.py test_*.py
Then pytest will only look for the test code in the From this point on, if I fix this problem, I have a hypothesis: Refer to pytest's filter logic for test files and filter out any logic that does not conform to the rules before passing the files to pytest for inspection. Since I was having conflicts with |
Remove integration of pylint-pytest as it seems to not produce very reliable results both locally on on CI. Even worse the way F6401 because only confused the user, making much harder to identify what was the root cause. Related: reverbc/pylint-pytest#21
Remove integration of pylint-pytest as it seems to not produce very reliable results both locally on on CI. Even worse the way F6401 because only confused the user, making much harder to identify what was the root cause. Related: reverbc/pylint-pytest#21
I did some debugging and came to a similar conclusion: if there's a way for the plugin to skip non-pytest files altogether, it'd fix the problem. Maybe even w/o taping into P.S. In my case, the underlying collection error was caused by the fact that the project uses implicit namespaces and so feeding full file path to modules confuses Python when it tries to resolve relative imports (because it doesn't know what the root package is). It is easy to reproduce once you run the proper command (in this case =========================================================================== ERRORS ===========================================================================
___________________________________________________ ERROR collecting octomachinery/github/models/events.py ___________________________________________________
octomachinery/github/models/events.py:17: in <module>
from ...utils.asynctools import aio_gather
E ImportError: attempted relative import beyond top-level package
Any = typing.Any
Iterable = typing.Iterable
Mapping = typing.Mapping
TYPE_CHECKING = False
TextIO = <class 'typing.TextIO'>
Type = typing.Type
Union = typing.Union
_GidgetHubEvent = <class 'gidgethub.sansio.Event'>
__builtins__ = <builtins>
__cached__ = '/home/runner/work/octomachinery/octomachinery/octomachinery/github/models/__pycache__/events.cpython-39.pyc'
__doc__ = 'Generic GitHub event containers.' __file__ = '/home/runner/work/octomachinery/octomachinery/octomachinery/github/models/events.py'
__loader__ = <_frozen_importlib_external.SourceFileLoader object at 0x7ff8f7a0ab80>
__name__ = 'models.events'
__package__ = 'models'
__spec__ = ModuleSpec(name='models.events', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7ff8f7a0ab80>, origin='/home/runner/work
/octomachinery/octomachinery/octomachinery/github/models/events.py')
annotations = _Feature((3, 7, 0, 'beta', 1), (3, 10, 0, 'alpha', 0), 16777216)
attr = <module 'attr' from '/home/runner/work/octomachinery/octomachinery/.tox/pre-commit/lib/python3.9/site-packages/attr/__init__.py'>
cast = <function cast at 0x7ff8f97e5430>
json = <module 'json' from '/opt/hostedtoolcache/Python/3.9.6/x64/lib/python3.9/json/__init__.py'>
pathlib = <module 'pathlib' from '/opt/hostedtoolcache/Python/3.9.6/x64/lib/python3.9/pathlib.py'>
uuid = <module 'uuid' from '/opt/hostedtoolcache/Python/3.9.6/x64/lib/python3.9/uuid.py'>
warnings = <module 'warnings' from '/opt/hostedtoolcache/Python/3.9.6/x64/lib/python3.9/warnings.py'>
___________________________________________________ ERROR collecting octomachinery/github/models/events.py ___________________________________________________
ImportError while importing test module '/home/runner/work/octomachinery/octomachinery/octomachinery/github/models/events.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/opt/hostedtoolcache/Python/3.9.6/x64/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
octomachinery/github/models/events.py:17: in <module>
from ...utils.asynctools import aio_gather
E ImportError: attempted relative import beyond top-level package
================================================================== short test summary info ===================================================================
ERROR octomachinery/github/models/events.py - ImportError: attempted relative import beyond top-level package
ERROR octomachinery/github/models/events.py
=========================================================== no tests collected, 2 errors in 0.09s ============================================================ P.P.S. Another problem is that the error message gives an example with a dummy file path making it hard to debug. I think the message could be improved to specifically mention what file exactly causes the problem, instead of saying it's |
Refs: * reverbc/pylint-pytest#20 * reverbc/pylint-pytest#21 TODO: Revert once reverbc/pylint-pytest#22 is merged.
I believe we have other use cases that Similar to #2 use case, test author can use separate modules (let's call them helper modules) to organize their fixtures/helpers if they have a large and complex test framework. In that case, if there's a coding error in one of the helper modules and causing the I'm now more inclined to temporary remove this |
I do not think so. Checking the test modules should load dependencies in the background anyway. If they are loaded properly, they'll return the fixtures. If not, they'll cause errors. So I'm pretty sure that pointing at the test files will identify the missing fixtures one way or another. |
This change applies the pre-existing patterns to identify if the files with collection problems are tests. It is then used to eliminate the false-positives of F6401 (cannot-enumerate-pytest-fixtures). As a side effect, this patch also includes precise file paths that may be used to reproduce the problem. Fixes reverbc#20 Fixes reverbc#21 Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
This change applies the pre-existing patterns to identify if the files with collection problems are tests. It is then used to eliminate the false-positives of F6401 (cannot-enumerate-pytest-fixtures). As a side effect, this patch also includes precise file paths that may be used to reproduce the problem. Fixes reverbc#20 Fixes reverbc#21 _Replayed; Source PR: https://github.com/reverbc/pylint-pytest/pull/22_ Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
This change applies the pre-existing patterns to identify if the files with collection problems are tests. It is then used to eliminate the false-positives of F6401 (cannot-enumerate-pytest-fixtures). As a side effect, this patch also includes precise file paths that may be used to reproduce the problem. Fixes reverbc#20 Fixes reverbc#21 Signed-off-by: Sviatoslav Sydorenko <wk@sydorenko.org.ua> _Replayed; Source PR: https://github.com/reverbc/pylint-pytest/pull/22_ Additionally, satisfied the https://github.com/pylint-dev/pylint-pytest's `.pre-commit-config.yaml` Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
This change applies the pre-existing patterns to identify if the files with collection problems are tests. It is then used to eliminate the false-positives of F6401 (cannot-enumerate-pytest-fixtures). As a side effect, this patch also includes precise file paths that may be used to reproduce the problem. Fixes reverbc#20 Fixes reverbc#21 Signed-off-by: Sviatoslav Sydorenko <wk@sydorenko.org.ua> _Replayed; Source PR: https://github.com/reverbc/pylint-pytest/pull/22_ Additionally, satisfied the https://github.com/pylint-dev/pylint-pytest's `.pre-commit-config.yaml` Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
This change applies the pre-existing patterns to identify if the files with collection problems are tests. It is then used to eliminate the false-positives of F6401 (cannot-enumerate-pytest-fixtures). As a side effect, this patch also includes precise file paths that may be used to reproduce the problem. Fixes reverbc#20 Fixes reverbc#21 Signed-off-by: Sviatoslav Sydorenko <wk@sydorenko.org.ua> _Replayed; Source PR: https://github.com/reverbc/pylint-pytest/pull/22_ Additionally, satisfied the https://github.com/pylint-dev/pylint-pytest's `.pre-commit-config.yaml` Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
Describe the bug
Can you explain the prompt 'F6401' when I run pylint
pylint-pytest plugin cannot enumerate and collect pytest fixtures. Please run `pytest --fixtures --collect-only path/to/current/module.py` and resolve any potential syntax error or package dependency issues (Can-enumerate-pytest-fixtures)
is the reason?I would like to know how it works, or why it appears, and sometimes has different outputs. The same code, sometimes two, sometimes more. I was depressed.
I did run
pytest --fixtures --collect-only
without any unusual hints and my tests were normal.Description:
After I fine-tune my existing code, including running
pylint
,pytest
, andisort
, everything works. I added a new packageexecutor
with three modules, one is the abstract module ofbase.py
, two are corresponding to different implementation modules(local.py
,docker.py
).Then I run
isort
, andpylint
works fineThen I import the base class and two implementation classes in the module's
__init__.py
file, and add a factory method.When I run
pylint
again, the input tells me that some of the test modules have problems with F6401.Again, I want to emphasize that everything was fine until I added this module. But now I just added the source code of this module, this exception will appear.
What makes it even more confusing to me is that the module I'm prompted doesn't include any fixtures. I ran
pylint
again and found that F6401 has more test modules (several times more than last time).I've been using PyLint for a new project to check for a mode-by-module migration, and when I migrate to this module, I can't continue.
To Reproduce
Package versions
(add any relevant pylint/pytest plugin here)
load-plugins = pylint_pytest,
Folder structure
File content :
When I start this code, I get F6401, and when I comment it out, everything is fine.
crawlerstack_spiderkeeper.executor::__init__.py
pylint output with the plugin :
Why is it different before and after?
(Optional) pytest output from fixture collection
Expected behavior
Everything is ok
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: