Consider making `fscacher.test` self-contained

[hosiet]

I was trying to solve the issue discussed in https://bugs.debian.org/1079398#10 . For Debian's autopkgtest infra to work properly, the following patch will be needed, as discussed in https://lists.debian.org/debian-python/2024/11/msg00016.html :

--- fscacher-0.4.1.orig/src/fscacher/tests/test_cache.py
+++ fscacher-0.4.1/src/fscacher/tests/test_cache.py
@@ -8,8 +8,8 @@ import subprocess
 import sys
 import time
 import pytest
-from .. import PersistentCache
-from ..cache import DirFingerprint, FileFingerprint
+from fscacher import PersistentCache
+from fscacher.cache import DirFingerprint, FileFingerprint

 platform_system = platform.system().lower()
 on_windows = platform_system == "windows"
--- fscacher-0.4.1.orig/src/fscacher/tests/test_util.py
+++ fscacher-0.4.1/src/fscacher/tests/test_util.py
@@ -1,5 +1,5 @@
 import pytest
-from ..cache import xor_bytes
+from fscacher.cache import xor_bytes


 @pytest.mark.parametrize(

I believe the logic is that tests should be self-contained, and not a subpackage under the fscacher namespace that utilizes relative import. Now I am wondering if that patch makes sense to you.

Besides, with this patch, the /src/fscacher/tests/ directory can also be moved to the top dir and not nested under /src/fscacher/. That is just a wishlist item and you can decide whether that is useful.

[yarikoptic]

ha, thanks @hosiet . I think this might be the first time^1 I "consciously" see a reason for using abs paths in the tests, but I think I am still missing how autopkgtest would "extract" them from within fscacher package for running? i.e. wouldn't without that extra step of moving into separate /tests/ (not just /src/fscacher/tests/) be desired?

Generally, I prefer tests/ folder to reside under submodule so it is easier to run selection of tests relevant to that specific submodule: e.g. tests for fscacher/blah/ to be under fscacher/blah/tests/ (if there was a blah/). And I thought it is a common pattern.

e.g. remains the setup adopted by numpy

❯ pwd
/home/yoh/proj/misc/numpy
❯ git describe
v2.3.0.dev0-27-g2ff895d7f7
❯ find -iname tests
./numpy/_core/tests
./numpy/_pyinstaller/tests
./numpy/compat/tests
./numpy/distutils/tests
./numpy/f2py/tests
./numpy/fft/tests
./numpy/lib/tests
./numpy/linalg/tests
./numpy/ma/tests
./numpy/matrixlib/tests
./numpy/polynomial/tests
./numpy/random/tests
./numpy/testing/tests
./numpy/tests
./numpy/typing/tests

But indeed there they use absolute imports of numpy itself:

❯ grep 'import' ./numpy/*/tests/*py | grep '\.\.'
❯ grep 'import numpy' ./numpy/*/tests/*py | head
./numpy/_core/tests/_natype.py:import numpy as np
./numpy/_core/tests/test_abc.py:import numpy as np
./numpy/_core/tests/test_api.py:import numpy as np
./numpy/_core/tests/test_api.py:import numpy._core.umath as ncu
./numpy/_core/tests/test_argparse.py:import numpy as np
./numpy/_core/tests/test_array_api_info.py:import numpy as np
./numpy/_core/tests/test_array_coercion.py:import numpy as np
./numpy/_core/tests/test_array_coercion.py:import numpy._core._multiarray_umath as ncu
./numpy/_core/tests/test_array_interface.py:import numpy as np
./numpy/_core/tests/test_arraymethod.py:import numpy as np
...

hence, with numpy practices in mind, I think I might (I would like first to understand better how autopkgtests sets up/runs tests)

• agree to use abs imports
• would like to keep tests where they are ;)

and we might then adopt similar practice consistently in other products (@mih also even more "generally" prefered absolute imports ;) )

^1: @jwodder could correct me if I am wrong, since he might have raised this topic in the past too

[hosiet]

Debian's autopkgtest already have multiple layers of abstraction and thus I am not an expert of it either. However, by looking at https://manpages.debian.org/unstable/dh-python/pybuild-autopkgtest.1.en.html , the basic idea of autopkgtest for python modules can be seen as follows:

[...] The test files are copied to a temporary directory, so that the tests will run against the installed Python modules, and not against anything in the source tree.

I believe the fact that the tests are extracted out without the presence of source tree is the fundamental reason of using abs import.