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