pytest silently stops importing plugins on ImportError #1479
Labels
status: critical
grave problem or usability issue that affects lots of users
type: backward compatibility
might present some backward compatibility issues which should be carefully noted in the changelog
type: bug
problem that needs to be addressed
Comments
|
Your Workaround has a bug, it Registers Plugins even on exceptions, thus registering the last value under New name |
|
Moving the Register part into the else part of the previous try should fix it |
|
That's what I meant with "but maybe this was just a consequence of ignoring the exception and continuing to run the loop" - I was debugging this via IRC with @craftyguy as I couldn't reproduce it on my local machine first, so it was cumbersome enough already 😉 That explains the second traceback, but not why the first was silently ignored. |
RonnyPfannschmidt
added
type: bug
This was referenced Mar 29, 2016
|
@The-Compiler did you manage to find a reproducible example? |
|
So it seems to do what I expected with a local plugin loaded via However when doing the same thing in a setuptools entry point, I only get a pytest warning: This should really be a hard error, IMHO - it's really easy to miss, especially when you're trying to figure out why the hell your commandline arguments aren't accepted and pytest doesn't even run 😉
from setuptools import setup
setup(
name="pytest-issue1479",
packages = ['plugin'],
# the following makes a plugin available to pytest
entry_points = {
'pytest11': [
'issue1479 = plugin.plugin',
]
},
)
import blah |
|
Hi! |
|
BTW, |
If you're talking about commercial work, have you considered getting a support contract with Merlinux? 😉
I don't think so, other than fixing the real underlying issue. The issue here is simply that there's no proper error displayed when a plugin fails to import something.
Blame the Seems allure-framework/allure-python#92 is open already. |
This was referenced May 22, 2016
|
Proposed fix in #1564. |
This was referenced Aug 19, 2016
This was referenced Nov 22, 2017
|
seeing this issue again on |
This was referenced Nov 28, 2017
|
@utkjad I can't reproduce: with: Do you have a reproducer? Can you show the full output you get? |
|
Wait - you say "If I revert pytest back to 3.2.5 the test suite runs fine." but this issue is about pytest hiding a traceback. It sounds like you're seeing an entirely different issue. |
This was referenced Nov 28, 2017
This was referenced Dec 6, 2017
This was referenced Apr 27, 2018
|
I'm also seeing this problem again on a Windows system where a dependency is missing. However, it is not pytest that's eating the exception here, but pluggy (which eats Since this is an issue in pluggy, I've created a separate issue to further track this: pytest-dev/pluggy#174 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yesterday @craftyguy was trying to contribute something to qutebrowser, and we spent the time debugging an interesting pytest/pluggy issue instead 😆
When he tried to run pytest (
tox -e py35-covwith this tox.ini), he got errors about missing arguments (added in my pytest.ini):Looking at
--versionoutput, only a subset of the plugins was loaded:However discovering them wasn't the issue:
We then patched pytest's
pluggy.pylike so:(printing the discovered entrypoints, printing the entrypoint name inside the for-loop, and showing all exceptions)
This finally showed us what was going wrong:
pytest-qtfailed to import due to some C++ ABI mismatch, but some outer layer swallowed the exception and didn't report anything at all!Also, I noticed this part which is very confusing:
ValueError: Plugin already registered: pytest-qt=<module 'pytest_travis_fold' from ...>- but maybe this was just a consequence of ignoring the exception and continuing to run the loop.The text was updated successfully, but these errors were encountered: