F40 Change Proposal: Remove Python Mock Useage (System-Wide)

Remove Python Mock Usage


This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

:link: Summary

python-mock has been deprecated since Fedora 34 - 6 releases ago, but is still in use in many packages. We plan to go through the remaining usages and clean them up, with the goal of retiring python-mock from Fedora.

:link: Owner

:link: Detailed Description

python-mock has been marked as deprecated since Fedora 34, but many packages are still using it

Binary packages from 16 source packages require python3-mock

$ fedrq whatrequires python3-mock -b rawhide -F source --notsrc | wc -l 16 $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock | grep -v src$ | wc -l 16 $ repoquery -q --repo=rawhide --whatrequires python3-mock --source | wc -l 16

124 source packages require python3-mock

$ fedrq whatrequires python3-mock -b rawhide -F source --src | wc -l 124 $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock | grep src$ | wc -l 124

For a combined 134 packages

$ fedrq whatrequires python3-mock -b rawhide -F source | wc -l 134 $ (repoquery -q --repo=rawhide{,-source} --whatrequires python3-mock | grep src$; repoquery -q --repo=rawhide --whatrequires python3-mock --source) | pkgname | sort | uniq | wc -l 134

Some of these are false positives - packages not using dynamic build requirements might still be marked as requiring python-mock after upstream no longer does so. The rest should be easily portable as described in the previous proposal.

Some packages could be dead upstream and not used by anything else in Fedora, in which case we can consider removing them.

:link: Feedback

:link: Benefit to Fedora

Eventually, we might be able to no longer maintain a standard library backport in a separate package.

This will also make branching packages for EPEL easier - there have been several instances where the Fedora package needs to be modified to not use python-mock because of a policy decision to not bring python-mock into newer EPEL releases (where the default Python already contains unittest.mock).

:link: Scope

  • Proposal owners:

    • Set up a COPR with a stub package providing python3-mock and rebuild all packages that list python3-mock as a BR. The ones that successfully build don’t actually need it
    • Put up PRs for the affected packages. In case the changes are minimal and no response is heard from the package maintainers the PRs will be merged after a sufficient time.
    • Set up a second COPR to rebuild packages with the PRs applied to remove python3-mock. This will allow us to track progress in one place
  • Other developers:

Package maintainers should review and merge any PRs filed against their packages, and if necessary forward the patches upstream (e.g. by filing upstream PRs).

  • Release engineering: N/A (not needed for this Change)

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives:

Not specifically, but this is in line with Fedora’s “First” Foundation

:link: Upgrade/compatibility impact


:link: How To Test

Package owners who receive a PR should be able to verify that the CI passes on the PR, and alternatively they can check the provided COPRs

:link: User Experience

No changes

:link: Dependencies


:link: Contingency Plan

  • Contingency mechanism: defer retiring python-mock for another cycle
  • Contingency deadline: Final Freeze
  • Blocks release? No

:link: Documentation

The previous howto on migrating to unittest.mock still applies.

Upstream unittest.mock documentation

:link: Release Notes

1 Like

This change proposal has now been submitted to FESCo with ticket #3140 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like

Could you consider adding a step before filing all the PR’s to post to the devel list the affected packages and a summary of needed changes? This may get the more active maintainers just fixing it and saving you a PR round trip… and also increase visibility before the PR’s show up.

1 Like

Good idea! Will do that (and generally send updates to devel and here at each stage)

1 Like

I think it’s a good time to get rid of python-mock, and I appreciate your work to lead the change.

There’s a minor typo in the title (s/Useage/Usage/).

1 Like