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?
On 1/10/22 06:55, Miro Hrončok wrote:
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).
This feels like a fairly sane default and I don't have any objections to it.
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:
- 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.
- 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).
- 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?
On Mon, Jan 10, 2022 at 01:55:39PM +0100, 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.
Yes please. I find myself having to add it several times, for packages that don't use Tox.
Best regards,
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:
- 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.
- 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).
- 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.
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:
- 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.
- 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).
- 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
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:
- 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.
- 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).
- 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
python-devel@lists.fedoraproject.org