You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[RPM Packaging] The format used in 'pyproject.toml' for 'packages' key does not seem to fit standards for RPM build #165
I am working in an organization that is using the TAP format, and in this goal we are building this tappy project as a '.rpm' package.
However since, the last release (v3.2) and especially since the modification of your build method, we are not able to package directly this project.
The good new is that I've found the cause of this issue.
Indeed, in your pyproject.toml file, there is this section:
And after some tests, it seems that the standard RPM tools[1] used to build a rpm package from a python repository does not always recognize this syntax. Simply changing this section to the following fixes the problem in my case.
I guess it depends on the version of hatchling used, but since it is not explicitly set in your project...
For information the hatchling version I'm using is 1.27.0.
Thanks for the report. Do you have confidence in the fix? There is an open PR for pytest-tap with a similar fix, but it doesn't work and leaves the built package with no files in it (python-tap/pytest-tap#105). I'm open to a fix, but it has to be something that work.
BTW, I'm a solo maintainer with drive-by contributors and I'm not actively working on the project lately. The odds of getting this fixed go up greatly with a PR. 😁 The test suite runs against tox, so it should be pretty clear if the fix works from a CI run. I won't have time to work on this this week.
Hi ! I have no problem to open a PR, I will try to do so in the next day. I usually open an issue before because sometime the maintainers of repositories would rather have an issue first and then a PR if they agree.
I will also have a look on the PR you mentioned. Thanks!
I will use two build commands: uv build (it is the one used here) and python3 -m pip wheel . (the one used in the rpm packaging environment and probably for Debian packaging as well).
Case 1: original pyproject.toml file + build command line: uv build
Results: I correctly have all the python files in the wheel.
So... there is something weird between how uv is building and how python3 -m pip wheel is building. What could be great to find is how we could conciliate both.
The positive point from this experiment is that it shows that the problem does not come from the hatchling version.
Activity
mblayman commentedon Oct 28, 2025
Thanks for the report. Do you have confidence in the fix? There is an open PR for pytest-tap with a similar fix, but it doesn't work and leaves the built package with no files in it (python-tap/pytest-tap#105). I'm open to a fix, but it has to be something that work.
BTW, I'm a solo maintainer with drive-by contributors and I'm not actively working on the project lately. The odds of getting this fixed go up greatly with a PR. 😁 The test suite runs against tox, so it should be pretty clear if the fix works from a CI run. I won't have time to work on this this week.
ArmandBENETEAU commentedon Oct 29, 2025
Hi ! I have no problem to open a PR, I will try to do so in the next day. I usually open an issue before because sometime the maintainers of repositories would rather have an issue first and then a PR if they agree.
I will also have a look on the PR you mentioned. Thanks!
ArmandBENETEAU commentedon Oct 29, 2025
So I have a bit of time today and I've started investigating. Let me write here my first observations.
I've forked the project, created the virtual environment locally on my laptop, installed
toxanduvand let's go!For each case I will also give the version of
hatchlingused.For the "modified file case", the modification I am doing is the following:
I will use two build commands:
uv build(it is the one used here) andpython3 -m pip wheel .(the one used in the rpm packaging environment and probably for Debian packaging as well).Case 1: original
pyproject.tomlfile + build command line:uv buildResults: I correctly have all the python files in the wheel.
Version of hatchling used: 1.27.0
Case 2: modified
pyproject.tomlfile + build command line:uv buildResults: I do not have any python file, just "dist-info" directory.
Version of hatchling used: 1.27.0
Case 3: original
pyproject.tomlfile + build command line:python3 -m pip wheel .Results: I do not have any python file, just "dist-info" directory.
Version of hatchling used: 1.27.0
Case 4: modified
pyproject.tomlfile + build command line:python3 -m pip wheel .Results: I correctly have all the python files in the wheel.
Version of hatchling used: 1.27.0
Conclusion
So... there is something weird between how
uvis building and howpython3 -m pip wheelis building. What could be great to find is how we could conciliate both.The positive point from this experiment is that it shows that the problem does not come from the
hatchlingversion.ArmandBENETEAU commentedon Oct 29, 2025
Solution found! See your PR #166 😉
mblayman commentedon Oct 30, 2025
Fixed with #166