On 19. 01. 22 13:27, Miro Hrončok wrote:
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
Guidelines update:
https://pagure.io/packaging-committee/pull-request/1155
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
