I ve got some odd behavior with a library we re trying to us

Question

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

high-yak-85899 · Answer

```import pyudev if name == main print pyudev version ``` A simple library like this works totally fine when I ` pants run` it

high-yak-85899 · Answer

```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 ``` 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 lt frozen importlib bootstrap gt 1014 in gcd import lt frozen importlib bootstrap gt 991 in find and load lt frozen importlib bootstrap gt 975 in find and load unlocked lt frozen importlib bootstrap gt 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 lt module gt import pyudev home nathanael cache pants named caches pex root venvs s 9b3c2bd3 venv lib python3 8 site packages pyudev init py 57 in lt module gt 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````

high-yak-85899 · Answer

In our `pytest ini` we have warnings raised as errors so maybe that s the case here It doesn t seem like it though

high-yak-85899 · Answer

This is all using their latest version `0 23 2`

bitter-ability-32190 · Answer

`SyntaxError invalid escape sequence ` is the important message

high-yak-85899 · Answer

Yup I m just not clear on what s different between the two execution modes

bitter-ability-32190 · Answer

There s a handful but I d expect that none of them would be very meaningful in this context thinking face

high-yak-85899 · Answer

From what I can tell it s the same python interpreter in both invocations

high-yak-85899 · Answer

high-yak-85899 · Answer

Here s the offending line

high-yak-85899 · Answer

I can happily open a python interpreter and paste that docstring in and have it be perfectly valid python

bitter-ability-32190 · Answer

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

high-yak-85899 · Answer

I m not too sure what to poke at is the problem

high-yak-85899 · Answer

It s already so minimal

bitter-ability-32190 · Answer

Right but thatd help us see what exactly is running

high-yak-85899 · Answer

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

bitter-ability-32190 · Answer

Oh I missed that part

bitter-ability-32190 · Answer

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 thinking face

high-yak-85899 · Answer

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

high-yak-85899 · Answer

No no I m not saying that

high-yak-85899 · Answer

I just expected to have the warning printed to the terminal kind of like a urlib unverified https warning would show up

bitter-ability-32190 · Answer

From <https docs python org 3 library warnings html> Warning messages are normally written to `sys stderr`

bitter-ability-32190 · Answer

So we should double check we re not suppressing stderr output

high-yak-85899 · Answer

Well now I can t reproduce the above Even forced things with ` no local cache`

bitter-ability-32190 · Answer

run roh see no evil