search

hhursev / recipe-scrapers

Python package for scraping recipes data
MIT License
1.6k stars 505 forks source link

Test fail with missing README.rst #1160

Open marillat opened 3 days ago

marillat commented 3 days ago

From https://bugs.debian.org/1074484

ERROR: test_includes (tests.library.test_readme.TestReadme.test_includes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/marillat/recipe-scrapers-14.57.0/.pybuild/cpython3_3.12_recipe-scrapers/build/tests/library/test_readme.py", line 117, in test_includes
    lines = get_list_lines()
            ^^^^^^^^^^^^^^^^
  File "/home/marillat/recipe-scrapers-14.57.0/.pybuild/cpython3_3.12_recipe-scrapers/build/tests/library/test_readme.py", line 94, in get_list_lines
    with open("README.rst") as f:
         ^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'README.rst'

----------------------------------------------------------------------
Ran 602 tests in 33.199s

FAILED (errors=1)
E: pybuild pybuild:389: test: plugin pyproject failed with: exit code=1: cd /home/marillat/recipe-scrapers-14.57.0/.pybuild/cpython3_3.12_recipe-scrapers/build; python3.12 -m unittest discover -v 
dh_auto_test: error: pybuild --test -i python{version} -p 3.12 returned exit code 13
jayaddison commented 3 days ago

Thanks for the bugreport @marillat - I can confirm this after attempting a build from the python-recipe-scrapers 14.57.0-1 source.

The failing TestReadme.test_includes test as-described reads from a fixed README.rst path -- but after the Python package is built, the content of that file is only found within the package's recipe_scrapers-{vesion}.dist-info/METADATA file -- as the package's readme content (ref: the relevant pyproject.toml config).

Replacing the README.rst file open with some logic to open the *.dist-info/METADATA file works; the test runs and passes again; however I don't think it'd be great practice to have a unit test in the codebase here that has logic that is only exercised when downstream distros perform builds.

So a larger re-work may be required here; perhaps the test code needs to discover whether package metadata is available, and if so to check the contents of that -- otherwise fallback to README.rst. If we can do that, we should be able to add that as a check to one of our continuous integration workflows (perhaps the publish -- release -- workflow).