From Fedora Project Wiki

Move module to python3-test subpackage


Move from python3-libs to python3-test subpackage.


Current status

Detailed Description

Python test modules should be used only for testing Python itself. However, some packages have buildtime or runtime dependency on parts of Python test modules. The aim of this change is to move the most popular Python test module from python3-libs to python3-test subpackage which will help us discover packages which depend on it and also identify parts of the module which might be useful to move to standard library.

Also, the Python documentation says is not a public module. Other things should not depend on it, and if something is useful outside the CPython test suite, we should ideally take it out of

Benefit to Fedora

The main benefit here is that moving it all to -test is less fragile and more consistent.

In the long run, it also helps us understand which parts of Python test suite are useful and which is worth to move to the standard library. (Note that the change owners have already done some pre-scoping, see the Scope section for the list of packages expected to be affected by this change.)

There were also a few bugs caused by parts of the test module packaged in different subpackages and by differences between Python 2 and 3 - RHBZ#1651245, RHBZ#1528899, RHBZ#596258


  • Other developers:
    • If a package depends on module which we move to -test subpackage, change the build/runtime dependencies definition accordingly.
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Test modules should not be used as a runtime dependency so there is no impact on an upgrade.

How To Test

N/A (not a System Wide Change)

User Experience

The user experience should not be affected.


N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: Changes will be mostly done in Python specfile and they can be easily reverted in case of some unexpected issues. The second possibility is to set Provides to temporarily deactivate the impact of the change.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)
  • Blocks product? No.


N/A (not a System Wide Change)

Release Notes

Since this affects only a few packages, no release notes are necessary.