simplify pyproject.toml #136
Conversation
|
So we are back with problem I had. Unless you have ideas for fixing github action workflows as well and can add them into PR. |
And be more explicit about included package data:
- make sure that manpage is included in the sdist tar archive
- include tests in sdist archive but not in the wheel
- eliminate deprecation warnings in newer setuptools versions
Since the build.yaml workflow explicitly installs the built system_calls
wheel, there is no need to add the current working directory (CWD) to
pytest's pythonpath.
Furthermore, in case a future update breaks the system_calls wheel
creation, the pytest invocation will not detect it,
because it imports the package from the working directory and
not from the installed location.
FWIW, in case you want to explicitly run the tests against the CWD,
e.g. during development, you can invoke pytest like this from the CWD:
python3 -m pytest -v
This works because it adds `.` to the pythonpath, by default,
in contrast to the `pytest ...` frontend.
closes hrw#131
gsauthof
force-pushed
the
pyproject-cleanup
branch
from
8979c08 to
6d549e6
Compare
|
Hm, weird, I tested that change before in a f42 VM where the subpackage was automatically included in the tar archive and wheel: From the github actions logs I can see that in the CI environment the subpackage is excluded, Python versions are quite similar (3.13.9 vs. 3.13.7), python build has the same version, etc. - perhaps GA setuptools version is weirdly different. Anyhow, according to the setuptools docs, one should actually specify the subpackage. I've thus updated the pull request to again explicitly include the subpackage. The new version also is more explicit about data files: |
|
Thanks! |
|
As usual - this will be released once there will be changes in system-calls data. |
2 participants
The subpackage system_calls.tables is already selected with:
packages = ["system_calls"]Since the build.yaml workflow explicitly installs the built system_calls wheel, there is no need to add the current working directory (CWD) to pytest's pythonpath.
Furthermore, in case a future update breaks the system_calls wheel creation, the pytest invocation will not detect it, because it imports the package from the working directory and not from the installed location.
FWIW, in case you want to explicitly run the tests against the CWD, e.g. during development, you can invoke pytest like this from the CWD:
This works because it adds
.to the pythonpath, by default, in contrast to thepytest ...frontend.closes #131