Python tests fail: No module named 'segyio._segyio'
yurivict opened this issue · comments
setup.py test fails:
_____________________________________________________________________________ ERROR collecting test/segyio_c.py ______________________________________________________________________________
ImportError while importing test module '/disk-samsung/freebsd-ports/science/py-segyio/work-py38/segyio-1.9.7/python/test/segyio_c.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
test/segyio_c.py:13: in <module>
import segyio._segyio as _segyio
E ModuleNotFoundError: No module named 'segyio._segyio'
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
================================================================================== 1 error in 0.62 seconds ===================================================================================
*** Error code 2
Python-3.8
FreeBSD 13
Is the python extension built and made available? Try setup.py build_ext --inplace build and see if the problem persists.
import segyio succeeds.
Not sure why does the test run import segyio._segyio,
The segyio_c tests specifically targets the C++ code in the extension, so it has to import it. Since loading it is expensive and makes (some) tests slightly harder to develop, it is not imported until it is requested. Starting fresh I'd not make the same mistake again, but this is expected behaviour as-of now.
After setup.py build_ext --inplace tests pass.
But this command isn't run during the package build. Does this mean that some functionality is missing?
No, not really, just that it's the more ergonomic approach. The problem is that setup.py build by default won't move the python extension (_segyio.so) into the source tree, and the build- and package scripts run the tests they do against the source tree. If you do setup.py install it will make sure to bring the _segyio.so file too, and the tests would pass again.
By doing it this way, some things are still functional even without building (or moving) the .so, and there was not too much incentive to change it, since anyone coming across it is likely a developer (or packager) and would want to build with --inplace or pip install -e . anyway.
Ok, thanks!
No problem!