Title: Add --disable-test-modules configure option to not build nor install tests
Type: enhancement Stage: resolved
Components: Build, Cross-Build Versions: Python 3.10
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Alex.Willmer, doko, edmorley, eschwartz, martin.panter, pxinwr, thomas-petazzoni, vstinner
Priority: normal Keywords: patch

Created on 2016-07-28 10:05 by xdegaye, last changed 2021-02-21 11:09 by vstinner. This issue is now closed.

File name Uploaded Description Edit
disable-test-suite.patch xdegaye, 2016-07-28 10:05 review xdegaye, 2016-07-28 10:05
pr23886_files.diff vstinner, 2020-12-29 23:54
Pull Requests
URL Status Linked Edit
PR 23886 merged pxinwr, 2020-12-28 13:48
Messages (14)
msg271514 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2016-07-28 10:05
Do not install the Python test suite when configure is run with '--disable-test-suite'. This about divides by two the size of the installed standard library.

Related to issue 26852: add the '--enable-legacy-pyc-files' option to configure.

The attached script may be used to check that the set of sub-directories in the std library is not changed by the patch.
msg271526 - (view) Author: Thomas Petazzoni (thomas-petazzoni) Date: 2016-07-28 11:21
We have a similar patch in Buildroot (see so we would be very happy to see this patch merged.

Note that we also have many more patches to disable various parts of the Python standard installation ( So either we have one option for each feature (like we have implemented), or a more general config option --disable-feature=test,this,that.

See also bug which is related, and was also proposing a patch to disable the test suite.
msg271619 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2016-07-29 11:57
Thanks for the review Martin. I will update the patch accordingly later.
msg287515 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-10 11:13
I'm in favor of allowing to build a "subset" of Python. Not only it makes sense for embedded devices, but in many cases it's even not possible to do otherwise: "full" Python is too big for small devices.

But I would prefer to see a public discussion on python-dev before going into this direction.

The previous attempt failed because some core developers were opposed to support officially a "subset of Python". But since this previous discussion (two years ago? longer?), MicroPython became popular, and this implementation of Python has a small subset of the stdlib (but it supports asyncio ;-)) Maybe it's time for a new attempt :-) Oh, and the meanwhile we also made progress on the Android port, which is now an important platform.

In short, I would like to official support Python subsets ;-) At least, add options for that.
msg287525 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-02-10 12:00
> But I would prefer to see a public discussion on python-dev before going into this direction.

Ah, the discussion restarted on the other issue:
msg304721 - (view) Author: Xavier de Gaye (xdegaye) * (Python triager) Date: 2017-10-21 20:11
> Ah, the discussion restarted on the other issue:

Issue 20210 has ended up as a change in the build system eventually and not the installation process, only a tiny step towards the configuration of a smaller Python distribution :(

After browsing again the last discussion on "[Python-ideas] size of the installation of Python on mobile devices" [1], I find all the arguments in favor of such changes still relevant. I would also add the following new arguments:

* One frequent argument used against those changes is that "[packagers for mobile and embedded devices] will have to patch the code base anyway to get things working in such an environment". But this is not true, see issue 30386 (Add a build infrastructure for Android) that proposes an addition to Python that does not modify a SINGLE LINE in the existing source code. So it is not true (or at least not anymore true) that packagers for mobile and embedded devices need to patch the code base anyway.

* When Python is installed by the termux [2] Android application on an Android device, the size of the installed standard library is 34M. The termux installation script does not install the following files [3]:

    bin/python${_MAJOR_VERSION}m bin/idle*

But it fails to not install also:

This is not consistent and should be fixed by a proper (endorsed by Python) installation process.

msg336937 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-01 17:22
I modified to add a new TEST_EXTENSIONS which allows to not build test extensions:

New changeset cfe172dc6bd0a02d36db31ffabcc38f9320a4510 by Victor Stinner in branch 'master':
bpo-36146: Add TEST_EXTENSIONS to (GH-12129) should be modified manually, but it's a small step towards be able to build Python without tests ;-)
msg384034 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-12-29 23:55
pr23886_files.diff: see
msg384063 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-12-30 12:50
New changeset 277ce3060becc120f1c877346562bd6880f4be71 by pxinwr in branch 'master':
bpo-27640: Add --disable-test-modules configure option (GH-23886)
msg384064 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-12-30 12:56
Thanks all, it's now fixed in the master branch, the future Python 3.10.

Thanks Xavier de Gaye for the initial patch and reported the issue.

Thanks Peixing Xin for the final change which is now even better! 

Thanks also Thomas Petazzoni who maintained the downstream patch in buildroot.

See also discussion on PR 23886 about the technical change and the different tests that we run to ensure that the change doesn't break anything, and that it works as expected.

I'm really not comfortable at all to change the Python build system. It's very complex and fragile, I don't know it very well, so I'm not confident in what I am doing. For these reasons, I'm strongly against backporting the change to stable branches (3.8 and 3.9) and so I close the issue
msg386758 - (view) Author: Eli Schwartz (eschwartz) Date: 2021-02-10 03:50
I have a slightly different interest in declining to install tests... Arch Linux provides the tests as a split subpackage with currently some hacky shell globbing to delete the tests after make install, then do a second libinstall and delete everything but the tests.

It would be more convenient if we had a Makefile option to install the tests separately.

It's now possible to disable installing tests with a filthy hack: make install TEST_MODULES= TESTSUBDIRS=

However, it's not possible to similarly hack make libinstall LIBSUBDIRS=
Because it installs some toplevel stuff, then runs lib2to3.pgen2.driver on the grammar that got skipped by the LIBSUBDIRS= hack.

Thoughts on maybe splitting this up at install time? Would probably mean duplicating some of libinstall as testinstall...
msg386823 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-02-11 08:02
> It would be more convenient if we had a Makefile option to install the tests separately.

While this use case is tighly coupled to this feature, would you mind to open a separate issue for your use case? IMO it makes sense and it sounds easy to implement it (especially after --disable-test-modules feature has been implemented).
msg387439 - (view) Author: Eli Schwartz (eschwartz) Date: 2021-02-21 04:53
I filed issue43282 for this.
msg387454 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-02-21 11:09
> I filed issue43282 for this.

Thanks ;-)
Date User Action Args
2021-02-21 11:09:37vstinnersetmessages: + msg387454
2021-02-21 04:53:14eschwartzsetmessages: + msg387439
2021-02-11 08:02:06vstinnersetmessages: + msg386823
2021-02-10 03:50:08eschwartzsetnosy: + eschwartz
messages: + msg386758
2020-12-30 12:56:22vstinnersettitle: add the '--disable-test-suite' option to configure -> Add --disable-test-modules configure option to not build nor install tests
2020-12-30 12:56:02vstinnersetstatus: open -> closed
versions: + Python 3.10, - Python 3.6
messages: + msg384064

resolution: fixed
stage: patch review -> resolved
2020-12-30 12:50:50vstinnersetmessages: + msg384063
2020-12-29 23:55:14vstinnersetmessages: + msg384034
2020-12-29 23:54:57vstinnersetfiles: + pr23886_files.diff
2020-12-28 13:48:52pxinwrsetnosy: + pxinwr
pull_requests: + pull_request22820
2019-12-10 08:06:04xdegayesetnosy: - xdegaye
2019-03-01 17:22:42vstinnersetmessages: + msg336937
2019-02-28 01:28:33yan12125setnosy: - yan12125
2017-12-10 09:30:59xdegayeunlinkissue26865 dependencies
2017-10-21 20:11:36xdegayesetmessages: + msg304721
2017-07-17 15:50:02edmorleysetnosy: + edmorley
2017-02-10 12:00:51vstinnersetmessages: + msg287525
2017-02-10 11:24:20yan12125setnosy: + yan12125
2017-02-10 11:13:19vstinnersetmessages: + msg287515
2017-02-03 18:47:06xdegayesetassignee: xdegaye ->
2016-07-29 11:57:42xdegayesetmessages: + msg271619
2016-07-28 11:21:44thomas-petazzonisetmessages: + msg271526
2016-07-28 10:47:19xdegayesetnosy: + vstinner, thomas-petazzoni
2016-07-28 10:34:30xdegayelinkissue26865 dependencies
2016-07-28 10:15:32xdegayesetnosy: + Alex.Willmer
components: + Cross-Build
2016-07-28 10:05:29xdegayesetfiles: +
2016-07-28 10:05:17xdegayecreate