6.0.5: pytest fails in 7 units about multidict

[kloczek]

This is not related to C-extensions. I don't know why you keep bringing it up. It's also not related to relative imports.

If DSO module is imported from some pyton file by import .foo it needs to be located at the same directory where is that file.
pep517 AFAIK do not support building module in-place to put linked DSO where is .py file.
On packaging as far as someone don't want to use venv it meas that it cannot be used methodology which I've described on top of this ticket.

BTW:

We don't want accidental imports from the source directory.

As long as is used pytest wrapper script instead python -m pytest on pytest execution is not used module code from source tree (python -m foo adds to sys.paths current directory). Only bits which are used are test suite files (test*py files found by pytest on scanning units).
Please have look on your CI

multidict/.github/workflows/ci-cd.yml

Line 298 in 8a591ca

python -Im pytest tests -v

in other words you are exposing yourself on that kind of situation.
It was many times repeated on pytest forum to NOT use python -m pytest.
Another thing about that line. Instead passing tests as param better is to have defined testpaths in pytest settings (if it is already defined that param may be redundant here).

[kloczek]

Just checked and this module has some DSOs and looks like python code uses relative imports which always causes that kind of issues.
Will try to prepare patch which removes use relative imports and test is it help.

[kloczek]

No it did not helped 🤔
Nevertheless using relative imports is nothing more than asking for troubles.
Here is my patch

--- a/multidict/_multidict_py.py
+++ b/multidict/_multidict_py.py
@@ -3,7 +3,7 @@
 from array import array
 from collections import abc

-from ._abc import MultiMapping, MutableMultiMapping
+from multidict._abc import MultiMapping, MutableMultiMapping

 _marker = object()

--- a/multidict/_compat.py
+++ b/multidict/_compat.py
@@ -9,6 +9,6 @@

 if USE_EXTENSIONS:
     try:
-        from . import _multidict  # type: ignore[attr-defined]  # noqa: F401
+        from multidict import _multidict  # type: ignore[attr-defined]  # noqa: F401
     except ImportError:
         USE_EXTENSIONS = False
--- a/multidict/__init__.py
+++ b/multidict/__init__.py
@@ -5,8 +5,8 @@
 several values for the same key.
 """

-from ._abc import MultiMapping, MutableMultiMapping
-from ._compat import USE_EXTENSIONS
+from multidict._abc import MultiMapping, MutableMultiMapping
+from multidict._compat import USE_EXTENSIONS

 __all__ = (
     "MultiMapping",
@@ -26,7 +26,7 @@
 try:
     if not USE_EXTENSIONS:
         raise ImportError
-    from ._multidict import (
+    from multidict._multidict import (
         CIMultiDict,
         CIMultiDictProxy,
         MultiDict,
@@ -35,7 +35,7 @@
         istr,
     )
 except ImportError:  # pragma: no cover
-    from ._multidict_py import (
+    from multidict._multidict_py import (
         CIMultiDict,
         CIMultiDictProxy,
         MultiDict,

Please let me know if you want this as PR.

[webknjaz]

This is not a problem. The tests use -I which drops your custom $PYTHONPATH. If you install properly, this won't be happening.

[kloczek]

Another though .. why those units are trying to import DSOs modules from python command line?
They've already have been tested by other units that it is possible to import them 🤔

[webknjaz]

Because circular imports must be tested in isolation and not rely on import caching from other tests.

[kloczek]

This is not a problem. The tests use -I which drops your custom $PYTHONPATH. If you install properly, this won't be happening.

Procedure which I've described opening ticket is typically used on packaging python modules as rpm packages. 😞
In other words those units are breaking "testing as installed" methodology 🤔

[webknjaz]

Also, I have no idea what you mean by DSO.

[webknjaz]

In other words those units are breaking \ñ"testing as installed" methodology 🤔

"testing as installed" is exactly what said tests are doing. Your tests are wrong and test "as injected by an arbitrary env var", which is different. We don't want accidental imports from the source directory.

[kloczek]

Because circular imports must be tested in isolation and not rely on import caching from other tests.

IIRC cruelty pytest always test circular imports 🤔
This is why none of the other modules test suites are doing what those units here are trying to do.

[kloczek]

Also, I have no idea what you mean by DSO.

DSO stands for Dynamic Shared Object.

[webknjaz]

This is why none of the other modules test suites are doing what those units here are trying to do.

That's entirety untrue. Many of my projects do this. Moreover, I borrowed the idea from pytest's own test suite.

[webknjaz]

python code uses relative imports which always causes that kind of issues.

This is also totally false, by the way.

[kloczek]

This is also totally false, by the way.

Can I read somewhere about that and/or can you explain that? 🤔
AFAIK uses relative imports causes:

• additional syscall to obtain current directory
• breaks testing on typical build procedures used on packaging causing to use additional venvs to test module code/DSOs.

[kloczek]

That's entirety untrue. Many of my projects do this. Moreover, I borrowed the idea from pytest's own test suite.

I have packaged ~1.24k modules as rpm packages. Many of them comes with own DSOs as well.
If that methodology is so widely spread I would be able to observe something which you have here in those test unis.
So far this case is first one and I must admit that I'm testing almost those modules using pytest (+99%)

[tkloczko@pers-jacek SPECS]$ grep -l ^%pytest python-*.spec|wc -l; ls -1 python-*.spec|wc -l
1220
1238

I have as well multiple of your modules

[tkloczko@pers-jacek SPECS]$ grep https://github.com/aio-libs/ *spec -l
python-aiobotocore.spec
python-aiohttp-cors.spec
python-aiohttp.spec
python-aiopg.spec
python-aioredis.spec
python-aiosignal.spec
python-async-lru.spec
python-async-timeout.spec
python-frozenlist.spec
python-multidict.spec
python-pytest-aiohttp.spec
python-sphinxcontrib-asyncio.spec
python-yarl.spec

so it is a bit odd that only here I was able to spot failing units on checking circular dependencies methodology which is used here.
I have already multiple tickets opened in your repos

[tkloczko@pers-jacek SPECS]$ grep https://github.com/aio-libs/ *spec |grep BUG
python-aiobotocore.spec:# BUG: pytest fais https://github.com/aio-libs/aiobotocore/issues/965
python-aiohttp-cors.spec:# BUG: test suite fails https://github.com/aio-libs/aiohttp-cors/issues/383
python-aiohttp.spec:# BUG: pytest fais https://github.com/aio-libs/aiohttp/issues/7255
python-aiohttp.spec:# BUG: sphinx fails https://github.com/aio-libs/aiohttp/issues/7230
python-aiopg.spec:# BUG: sphinx fails https://github.com/aio-libs/aiopg/issues/898
python-aioredis.spec:# BUG: pytest is https://github.com/aio-libs/aioredis-py/issues/1406
python-async-timeout.spec:# BUG: test suite warnings https://github.com/aio-libs/async-timeout/issues/203
python-frozenlist.spec:# BUG: sphinx fails https://github.com/aio-libs/frozenlist/issues/570
python-sphinxcontrib-asyncio.spec:# BUG: missing test suite? https://github.com/aio-libs/sphinxcontrib-asyncio/issues/9
python-yarl.spec:# BUG: build fails https://github.com/aio-libs/yarl/issues/969
python-yarl.spec:# BUG: sphinx is failing https://github.com/aio-libs/yarl/issues/970

and I do not remember anything similar (.. maybe my memory tricks me).

[kloczek]

python code uses relative imports which always causes that kind of issues.

This is also totally false, by the way.

I many in this case I've been trying to tell that generally use relative imports causes problems with importing modules on use "test as installed" methodology used on packaging.

[webknjaz]

This is not related to C-extensions. I don't know why you keep bringing it up. It's also not related to relative imports. As I explained earlier, this is because -I is incompatible with setting env vars externally as it prevents them from leaking into the subprocess invoked during testing.
You can either patch out that option or start installing the library into the site-packages of your test env. These are very simple instructions to follow. I don't have anything else to add.

[webknjaz]

python code uses relative imports which always causes that kind of issues.

This is also totally false, by the way.

I many in this case I've been trying to tell that generally use relative imports causes problems with importing modules on use "test as installed" methodology used on packaging.

I don't think you understand how imports work but I also don't have time to educate you so you'll just have to take my word for it 🤷‍♂️