PEP 725: Specifying external dependencies in pyproject.toml

[tiran (Christian Heimes)]

@rgommers

I don’t think this is right. In (almost?) every packaging system, the build-time and runtime dependencies for a package are given by package names of other packages, not specific files from another dependency. That seems mostly true for Fedora as well, e.g. from spglib.spec almost all Requires: and BuildRequires: dependency specifiers are package names. The exception there is BuildRequires: cmake(GTest), which is equivalent to using the package name like BuildRequires: gtest-devel (please correct me if I’m wrong there, since I’m not all that familiar with Fedora).

BuildRequires: cmake(GTest) and BuildRequires: gtest-devel are not equivalent. Right now they happen to both install the same package. That may or may not change in the future. The name cmake(GTest) satisfies the requirement for cmake’s find_package(GTest). The additional provides make the lives of package maintainers easier. They don’t need to locate the right package for a cmake requirement. The system can figure out the right RPM package for the maintainer.

RPMs provide additional names to decouple the package name from its content. A lot of provides, requires, and build requires are automatically injected by RPM macros and the build system. The cmake and pkgconfig provides are not in in gtest.spec. They are added by the RPM build system.

$ dnf repoquery --provides gtest-devel
cmake(GTest) = 1.13.0
cmake(gtest) = 1.13.0
gtest-devel = 1.13.0-3.fc39
gtest-devel(x86-32) = 1.13.0-3.fc39
gtest-devel(x86-64) = 1.13.0-3.fc39
pkgconfig(gtest) = 1.13.0
pkgconfig(gtest_main) = 1.13.0

@rgommers

@tiran

I have created GitHub - python-wheel-build/elfdeps: Python implementation of RPM elfdeps

Thanks for sharing @tiran. Is that meant for Fedora’s needs, or do you see that playing a role in Python packaging?

Right now the output of the tool is RPM specific and only useful on RPM based distros (Fedora, RHEL, OpenSUSE, CentOS). I’m not familiar enough with other Linux distros to assess their needs. I’m open to extend the tool if there is a use case in the Python packaging ecosystem. The main use case are wheels that link to system libraries. The information from the tool lets us automatically install RPMs and detect ABI conflicts.