python packaging assistance sought for xgboost
by Nathan Scott
Hi all,
I've recently been packaging xgboost for Fedora. It's a C++ project using cmake, with a python module on the side (all in one source tarball): https://nathans.fedorapeople.org/xgboost/
The dependent dmlc-core package is here: https://nathans.fedorapeople.org/dmlc-core/
Everything is prepared and working from the C++ and shared library perspectives, but I'm struggling with getting the python module to install using latest Fedora python spec guidelines. Can anyone point out where I've gone wrong? (looks like its during the final python step in the spec %install)
https://nathans.fedorapeople.org/xgboost/xgboost.spec+python shows my additions to add the python sub-package and this is the error I now see (this is from the "%pyproject_save_files xgboost" line right at the end of %install):
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in <module>
main(cli_args)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main
file_section, module_names = pyproject_save_files_and_modules(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 720, in pyproject_save_files_and_modules
generate_file_list(paths_dict, globs, include_auto)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 534, in generate_file_list
raise ValueError(f"Globs did not match any module: {missed_text}")
ValueError: Globs did not match any module: xgboost
error: Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
4 months, 1 week
pyproject-rpm-macros 1.11.0: %pyproject_save_files gains the -l flag
(and more)
by Miro Hrončok
Hello Pythonistas,
pyproject-rpm-macros 1.11.0 is available in Rawhide + updates-testing for older
releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
I plan to sync it to c9s eventually early next year.
It contains one new feature and several smaller bugfixes:
The new -l/-L flag to %pyproject_save_files
===========================================
As said by Maxwell G on this list [1]:
> %pyproject_save_files automatically handles marking license files
> with %license when a build backend installs them into a package's
> dist-info directory and the License-File header is specified in the
> METADATA file. Currently, only setuptools and hatchling meet this
> criteria. Notably, poetry and flit do not support this. They will
> install license texts into the dist-info directory, but they do not add
> the License-File metadata. The License-File tag is not standardized, and
> discussion on PEP 639 which defines this standard has stalled. I believe
> relying on this feature is a problem, as if a project changes build
> systems or some other config and a packager doesn't realize, suddenly
> the license file won't be marked with %license or even worse, not
> installed at all. Since the pyproject macros read the build backend from
> pyproject.toml without packagers having to manually specify anything
> (which is generally great!), this situation seems likely to occur.
You can now use `%pyproject_save_files -l` to assert at least one license file
was detected and marked as %license. This is good in case you want a protection
from an accidental silent drop of the %license file in a next release.
Note that the -l flag only asserts *at least one license file was detected*.
It can still mean one of multiple files are silently dropped during a package
upgrade, but that's unlikely to happen for unrelated reasons (such as a change
of a build backend upstream).
For the time being, this assertion is opt-in only. Use `%pyproject_save_files
-L` if you list the %license file manually and you would like to explicitly
opt-out from this check in case it ever becomes the default (no such plan
exists for the time being).
(Note that this still needs to be documented in the Python packaging guidelines.)
Prevent incorrect usage of %pyproject_buildrequires -R with -x/-e/-t
====================================================================
Using `%pyproject_buildrequires -R` with -x, -t, or -e previously silently
discarded the -R option. Combining either of the flags with -R is actually not
possible and will now error properly.
https://bugzilla.redhat.com/2244282
Show a better error message when %pyproject_install finds no wheel
==================================================================
When there is no wheel to install (e.g. when you forget to run
%pyproject_wheel), the underlying pip error message was leaking:
ERROR: You must give at least one requirement to install (maybe you meant "pip
install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?)
It has been explicitly changed to:
ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir}
/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir
https://bugzilla.redhat.com/2242452
Fix %pyproject_buildrequires -w when build backend is installed and pip isn't
=============================================================================
Packages using `%pyproject_buildrequires -w` would fail to build if the build
backend was already (manually) installed before pip.
This was happening e.g. when testing a local version of the RPM with the build
backend and running something like:
$ mock init
$ mock install ../my-rpms/pytohn3-hatchling-1.2.3-1.fc50.noarch.rpm
$ fedpkg mockbuild -N
But it was also possible to achieve with manual BuildRequires:
BuildRequires: pytohn3-hatchling
...
%generate_buildrequires
%pyproject_buildrequires -w
The %pyproject_buildrequires macro generated a BuildRequires on pip, but it
attempted to build a wheel using pip before the generated pip dependency was
installed. This has now been fixed and the macro will "restart" in case pip is
not yet available to build the wheel.
https://bugzilla.redhat.com/2169855
-----------------------------------
Happy packaging.
Special thanks to Maxwell G, Karolina Surma, and Benjamin Beasley for help with
this release.
[1]
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 months, 1 week
