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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok