Hence, I propose we make the -r flag the default. In case some package needs to opt-out for legitimate reasons, a new flag would exist to disable it (most likely -R). While technically a backwards-incompatible change, I belive the negative impact should be minimal -- at worst packages that fail to install will now also fail to build (which is a good thing IMHO).

Hence, I propose we make the -r flag the default. In case some package needs to opt-out for legitimate reasons, a new flag would exist to disable it (most likely -R).

Hello Pythonistas. When we invented the %pyproject_buildrequires BuildRequires generator, it generated build-dependencies. Imediatelly we realized that for several reasons, also generating the runtime dependencies as BuildRequires is needed:  - they are needed to run the test suite  - they are needed to run an import check  - they make the build fail when runtime dependencies are not found Hence, %pyproject_buildrequires -r was introduced. This flag is implied by other flags (-x, -t, -e) but it is not a default behavior. However, as I've done a fair amount of new package reviews and pull request reviews to convert packages to pyproject-rpm-macros, I've noticed packagers have a tendency to forgot the -r flag when: 1) The currently packaged version has no runtime dependencies. This is currently quite harmless, as when the package is updated with new dependencies, the packager will notice and add the flag. However, if we ever have some automation for updates, we better have forward-compatible specfiles. 2) The runtime dependencies are pulled in as transitive dependencies of manually BuildRequired packages. For example, if there is `BuildRequires: python3-pytest` and the package runtime-requires toml, the tests will suceed with pytest 6 (requires toml) but will error with pytest 7 (as it migrated from toml to tomli). 3) There is not a single check run in %check. While technically forbidden by the new guidelines, this is not enforced and hence packages use %pyproject_buildrequires but don't run any tests. This can result in packages that are updated into an uninstallbale state. I'd rather the build failed in that case. Hence, I propose we make the -r flag the default. In case some package needs to opt-out for legitimate reasons, a new flag would exist to disable it (most likely -R). While technically a backwards-incompatible change, I belive the negative impact should be minimal -- at worst packages that fail to install will now also fail to build (which is a good thing IMHO). Thoughts?

On 19. 01. 22 11:43, Miro Hrončok wrote: > On 10. 01. 22 13:55, Miro Hrončok wrote: >> Hello Pythonistas. >> >> When we invented the %pyproject_buildrequires BuildRequires generator, it >> generated build-dependencies. Imediatelly we realized that for several >> reasons, also generating the runtime dependencies as BuildRequires is needed: >> >>   - they are needed to run the test suite >>   - they are needed to run an import check >>   - they make the build fail when runtime dependencies are not found >> >> Hence, %pyproject_buildrequires -r was introduced. This flag is implied by >> other flags (-x, -t, -e) but it is not a default behavior. >> >> However, as I've done a fair amount of new package reviews and pull request >> reviews to convert packages to pyproject-rpm-macros, I've noticed packagers >> have a tendency to forgot the -r flag when: >> >> >> 1) The currently packaged version has no runtime dependencies. >> >> This is currently quite harmless, as when the package is updated with new >> dependencies, the packager will notice and add the flag. However, if we ever >> have some automation for updates, we better have forward-compatible specfiles. >> >> >> 2) The runtime dependencies are pulled in as transitive dependencies of >> manually BuildRequired packages. >> >> For example, if there is `BuildRequires: python3-pytest` and the package >> runtime-requires toml, the tests will suceed with pytest 6 (requires toml) >> but will error with pytest 7 (as it migrated from toml to tomli). >> >> >> 3) There is not a single check run in %check. >> >> While technically forbidden by the new guidelines, this is not enforced and >> hence packages use %pyproject_buildrequires but don't run any tests. This >> can result in packages that are updated into an uninstallbale state. I'd >> rather the build failed in that case. >> >> >> >> Hence, I propose we make the -r flag the default. In case some package needs >> to opt-out for legitimate reasons, a new flag would exist to disable it >> (most likely -R). >> >> While technically a backwards-incompatible change, I belive the negative >> impact should be minimal -- at worst packages that fail to install will now >> also fail to build (which is a good thing IMHO). >> >> Thoughts? > > Given the general agreement here, here it is: > > https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/233 > > In copr, it broke 3 packages in a way that we want and it broke 2 packages > that were not compatible with -r and I proposed fixes for them. This landed in pyproject-rpm-macros-0-53