Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing is unable to find test.py #669

Closed
mtelka opened this issue May 11, 2023 · 5 comments
Closed

Testing is unable to find test.py #669

mtelka opened this issue May 11, 2023 · 5 comments

Comments

@mtelka
Copy link
Contributor

mtelka commented May 11, 2023

$ tox -e py39
.pkg: _optional_hooks> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True poetry.core.masonry.api
.pkg: get_requires_for_build_sdist> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True poetry.core.masonry.api
.pkg: prepare_metadata_for_build_wheel> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True poetry.core.masonry.api
.pkg: build_sdist> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True poetry.core.masonry.api
py39: install_package> python -I -m pip install --force-reinstall --no-deps /tmp/sh-2.0.3/.tox/.tmp/package/3/sh-2.0.3.tar.gz
py39: commands[0]> python test.py
/tmp/sh-2.0.3/.tox/py39/bin/python: can't open file '/tmp/sh-2.0.3/test.py': [Errno 2] No such file or directory
py39: exit 2 (0.07 seconds) /tmp/sh-2.0.3> python test.py pid=7954
.pkg: _exit> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True poetry.core.masonry.api
  py39: FAIL code 2 (5.55=setup[5.48]+cmd[0.07] seconds)
  evaluation failed :( (6.17 seconds)
$
@ecederstrand
Copy link
Collaborator

It would be helpful if you provide some more information. Where did you find the advice to run tests this way? How did you set up your test environment?

In general, there are two ways to run tests - Using Docker as described in the README, or using poetry as documented in https://github.com/amoffat/sh/blob/1c0dc81fb7fb7fd1d23d80082498ad3059154e79/.github/workflows/main.yml

@mtelka
Copy link
Contributor Author

mtelka commented May 12, 2023

I'm packaging sh for OpenIndiana (together with hundreds other Python projects) and during the package build the build framework runs tests. When a project supports tox (i.e. tox.ini file is present) then the default and so far almost always[1] working way to run tests is just to invoke something similar to tox -e py39[2].

Since I package sh for an operating system where the package will be run in real and current environment (not in a virtual one) then there is little sense to test sh using docker for my use case.

If I parsed the main.yaml file properly then the actual command to run tests should be this:

SH_TESTS_RUNNING=1 SH_TESTS_USE_SELECT=${{ matrix.use-select }} LANG=${{ matrix.lang }} poetry run coverage run -a -m unittest

Thanks for the hint. I'll play with it and report back.

[1] IIRC, sh is first case with tox.ini file available and supported when running tests using tox is ... unsupported(?); there is/was similar problem with poetry_core, but it looks like they decided to remove support for tox.
[2] We use a bit more complex test setup than that, but that's not important for now.

@ecederstrand
Copy link
Collaborator

Running tests using tox is supported, but only within the Docker container provided in tests/Dockerfile. I agree it's a bit misleading to provide a top-level tox.ini that's not intended to be run directly from the current system. I think we should just move our tox.ini to tests/tox.ini. Would that help your automated packaging script?

@mtelka
Copy link
Contributor Author

mtelka commented May 12, 2023

It looks like simple unittest testing works properly. That's just python -m unittest. This does require neither poetry, nor coverage. Both looks like unneeded overhead for integration testing needed for my packaging effort.

The move of current tox.ini to tests/tox.ini is probably good idea to avoid future confusion. For my particular case it won't help much because since I already know that the tox testing does not work as I would expect I simply switched to unittest and I no longer care about top-level tox.ini.

@amoffat
Copy link
Owner

amoffat commented Aug 7, 2023

Marking this as closed. If there is any followup discussion please re-open.

@amoffat amoffat closed this as completed Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants