Closed atodorov closed 2 years ago
@danielnoord @Pierre-Sassoulas do you happen to know what in 2.15 caused this? You might get some pylint-django bugs on the main pylint tracker from this, point them here if so. @atodorov I'll also try to find time too over the weekend, it's probably a deprecation I never got around to removing.
We did not move the TypeChecker
:
So the reason of the crash is not straightforward, it seems like a bug. But this ring a bell. Maybe something to do with plugin discoverability, the order of option and using load-plugin both in pylintrc and CLI options (as not yet documented in https://github.com/PyCQA/pylint/pull/7276 ?). Does the following would help ?
The preferred way of making this plugin available to pylint is by installing it as a package. This can be done either from a packaging index like
PyPI
or by installing it from a local source such as withpip install .
.Alternatively, the plugin module can be made available to pylint by putting this module's parent directory in your ``PYTHONPATH`` environment variable. If your pylint config has an init-hook that modifies ``sys.path`` to include the module's parent directory, this will also work, but only if either: * the ``init-hook`` and the ``load-plugins`` list are both defined in a pylintrc file, or... * the ``init-hook`` is passed as a command-line argument and the ``load-plugins`` list is in the pylintrc file This is because pylint loads plugins specified on command line before loading any configuration from other sources.
So the reason of the crash is not straightforward, [...]
I can confirm this. We see the same issue in our pipeline, but I cannot reproduce it locally. I'm still figuring out what the slight differences between the CI environment and my laptop are but it's not only the versions mentioned in the initial post.
but it's not only the versions mentioned in the initial post
For me it's the same CI environment, same test job, only versions are different. Updated original comment with URL to passing job if you want to compare logs (before I applied a workaround).
I also can't seem to reproduce this locally with:
git checkout https://github.com/kiwitcms/trackers-integration.git
cd trackers-integration
virtualenv venv python3.8
pip install -r devel.txt
git clone --depth 1 https://github.com/kiwitcms/Kiwi.git "../Kiwi/"
pip install -r ../Kiwi/requirements/devel.txt
pip install pylint==2.15
make check
I'm getting one missing-timeout
error which seems correct, but no failure. Is anybody able to reproduce this locally? And not in CI?
I also couldn't reproduce it with python 3.8.12
or 3.9.9
or 3.10.1
locally.
I looked at the trackers-integration
CI config in case anything stood out, but didn't see anything. I thought perhaps that the github setup-python
action could have changed but it is tagged at v4. No new python 3.8 releases either recently. Basically I was wondering if there are any CI requirements that are not completely pinned that could have changed.
Maybe something to do with plugin discoverability, the order of option and using load-plugin both in pylintrc and CLI options (as not yet documented in https://github.com/PyCQA/pylint/pull/7276?).
We also had this issue and were able to fix it by removing the line load-plugins = ["pylint_django"]
from pyproject.toml
. pylint-django==2.5.3
is installed via pip.
Update: That probably disabled the plugin pylint-django
altogether. We're using pytest-pylint to run pylint and I was confused by the line plugins: django-4.5.2, pylint-0.18.0, mock-3.8.2
, but that's talking about pytest-django of course.
I also couldn't reproduce it with python
3.8.12
or3.9.9
or3.10.1
locally.
I also was not able to reproduce locally. I am still fairly busy this week but is there any more information I can provide to figure out why the CI environment is different?
I can drop a hint that it seems to hinge on astroid. astroid 2.12.4 reproduces this reliably for me with both pylint 2.14.5 and 2.15.0. Working combination is astroid 2.11.7 with pylint 2.14.5.
git bisect says this was caused by https://github.com/PyCQA/astroid/commit/5067f08affc912860b20f03fa5476d536e986745 (PR: https://github.com/PyCQA/astroid/pull/1536)
It has been fixed in commit https://github.com/PyCQA/astroid/commit/8852ecda407598636fcd760877e5a093148e8e67 (PR: https://github.com/PyCQA/astroid/pull/1759) released with astroid 2.12.5 yesterday (2022-08-29).
I've verified the fix with 2 of our repositories that failed with astroid 2.12.4.
Thanks a lot for the double bisection @michael-k, very helpful ! Reinstalling pylint from scratch or upgrading astroid manually should fix the issue then.
Can any of the original reporters confirm that this has indeed been fixed? I would be somewhat surprised as the original stracktrace seems to point to pylint
being at fault here, not astroid
.
@DanielNoord :
astroid-2.12.5, pylint-2.15.0, pylint-django-2.5.3, pylint-plugin-utils-0.7
Seems to work for me, see https://github.com/kiwitcms/trackers-integration/runs/8094609902?check_suite_focus=true.
The reported FAIL in the CI job above is pylint reporting errors on the code under inspection but it doesn't crash like in the original comment. From my POV this is now fixed.
Ok so it looks like there's an incompatibility with exactly astroid 2.12.4
or something, but that this will only be a problem for projects who have pinned that exact version. pylint-django
and pylint-plugin-utils
explicitly only declare very permissive pylint
version ranges and nothing else as a dependency to avoid clashes with other CI and linting dependencies.
I think this is just stale pip caches in CI to be honest; especially as nobody could reproduce it locally with a fresh venv. Doesn't seem like a problem which can be fixed in this repo so I'll close this.
Thanks for all the input and work everyone :-) especially the git bisect work to find the cause!
https://github.com/kiwitcms/trackers-integration/runs/8037795176?check_suite_focus=true
Previous PASSING execution in my CI, https://github.com/kiwitcms/trackers-integration/runs/7983170188?check_suite_focus=true, was with
@carlio I'm not sure if I will be able to take a look at this over the weekend. I will try.