I think this makes perfect sense. It would be generally helpful for the
reasons stated, and it’s hard to imagine any cases in which it could be
On 1/10/22 07: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).