https://pantsbuild.org/ logo
Join Slack
Powered by
I've got some odd behavior with a library we're tr...
# general
h
I've got some odd behavior with a library we're trying to use, 
pyudev
. Some details in the thread, but TLDR is there's different behavior between using this library in a test and source code.
Copy code
import pyudev

if __name__ == '__main__':
    print(pyudev.__version__)
A simple library like this works totally fine when I 
./pants run
it.
Copy code
import unittest

import pyudev


class SomeTest(unittest.TestCase):
    def test_things(self):
        print(pyudev.__version__)
A simple unit test like this fails with the following traceback
Copy code
(mono-venv) ~/devel/monorepo (test-out-pyudev)$ ./pants test astranis-python/astranis/instruments/pyudev/library_test.py
14:43:14.87 [ERROR] Completed: Run Pytest - astranis-python/astranis/instruments/pyudev/library_test.py:tests failed (exit code 2).
============================= test session starts ==============================
platform linux -- Python 3.8.10, pytest-7.0.1, pluggy-1.0.0
rootdir: /tmp/process-executionhKazxr, configfile: pytest.ini
plugins: typeguard-2.12.1, timeout-2.1.0, cov-3.0.0
timeout: 60.0s
timeout method: signal
timeout func_only: False
collected 0 items / 1 error

==================================== ERRORS ====================================
_ ERROR collecting astranis-python/astranis/instruments/pyudev/library_test.py _
/home/nathanael/.cache/pants/named_caches/pex_root/venvs/s/9b3c2bd3/venv/lib/python3.8/site-packages/_pytest/python.py:599: in _importtestmodule
    mod = import_path(self.path, mode=importmode, root=self.config.rootpath)
/home/nathanael/.cache/pants/named_caches/pex_root/venvs/s/9b3c2bd3/venv/lib/python3.8/site-packages/_pytest/pathlib.py:533: in import_path
    importlib.import_module(module_name)
/usr/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1014: in _gcd_import
    ???
<frozen importlib._bootstrap>:991: in _find_and_load
    ???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:671: in _load_unlocked
    ???
/home/nathanael/.cache/pants/named_caches/pex_root/venvs/s/9b3c2bd3/venv/lib/python3.8/site-packages/_pytest/assertion/rewrite.py:171: in exec_module
    exec(co, module.__dict__)
astranis-python/astranis/instruments/pyudev/library_test.py:3: in <module>
    import pyudev
/home/nathanael/.cache/pants/named_caches/pex_root/venvs/s/9b3c2bd3/venv/lib/python3.8/site-packages/pyudev/__init__.py:57: in <module>
    from pyudev.monitor import Monitor, MonitorObserver
E     File "/home/nathanael/.cache/pants/named_caches/pex_root/venvs/s/9b3c2bd3/venv/lib/python3.8/site-packages/pyudev/monitor.py", line 137
E       """
E       ^
E   SyntaxError: invalid escape sequence \
- generated xml file: /tmp/process-executionhKazxr/astranis-python.astranis.instruments.pyudev.library_test.py.tests.xml -
=========================== short test summary info ============================
ERROR astranis-python/astranis/instruments/pyudev/library_test.py
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 0.29s ===============================



āœ• astranis-python/astranis/instruments/pyudev/library_test.py:tests failed in 2.28s.

Wrote test XML to `dist/test_results`
In our 
pytest.ini
, we have warnings raised as errors, so maybe that's the case here? It doesn't seem like it, though.
This is all using their latest version, 
0.23.2
b
SyntaxError: invalid escape sequence \
is the important message
h
Yup. I'm just not clear on what's different between the two execution modes.
b
There's a handful, but I'd expect that none of them would be very meaningful in this context šŸ¤”
h
From what I can tell, it's the same python interpreter in both invocations.
Here's the offending line
I can happily open a python interpreter and paste that docstring in and have it be perfectly valid python.
b
Can you use 
./pants --no-process-cleanup test ...
and use the sandbox to start poking around? That'd be really helpful. The sandbox dir will be logged on the cmdline, and you can use 
./__run.sh
to run the process
h
I'm not too sure what to poke at is the problem.
It's already so minimal
b
Right but thatd help us see what exactly is running.
h
It's because we raise warnings as errors in tests. When I remove that from our 
pytest.ini
, things are fine. I just had expected to see the warning pop up when I 
./pants run
the other example.
b
Oh I missed that part
Sounds like you're just saying that you want warnings promoted to errors for 
./pants run
? I'm not sure thats something our users would expect šŸ¤”
h
The weird part is that when I ran this with 
pytest
directly, it passed. Edit: for clarity, with our 
pytest.ini
file set to raise warnings as errors
No no, I'm not saying that.
I just expected to have the warning printed to the terminal (kind of like a urlib unverified https warning would show up)
b
From https://docs.python.org/3/library/warnings.html "Warning messages are normally written to 
sys.stderr
"
So we should double-check we're not suppressing stderr output
h
Well now I can't reproduce the above. Even forced things with 
--no-local-cache
b
run roh šŸ™ˆ
5 Views
Open in Slack
PreviousNext
Powered by