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
harmful.
– Ben
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).
Thoughts?
_______________________________________________
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
