➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2021-02-21 04:49 by eschwartz, last changed 2022-04-11 14:59 by admin.
| Messages (3) | |||
|---|---|---|---|
| msg387438 - (view) | Author: Eli Schwartz (eschwartz) * | Date: 2021-02-21 04:49 | |
cf. https://bugs.python.org/issue27640#msg386758 Carrying on from the addition of --disable-test-modules, I would find it convenient to be able to still provide the tests, but install them separately. The end result would be two distro packages, one slim package that does not include the test modules by default, and one package that adds in the test modules for people that need it. This is currently possible via running the install step twice and some hacky shell globbing to delete unneeded files from each install. Some sort of libinstall/testinstall target split target would be less hacky, and not require checking if the list of test modules is up to date. So I'd consider it nice to have. :) |
|||
| msg387453 - (view) | Author: STINNER Victor (vstinner) *  |
Date: 2021-02-21 11:09 | |
Do you want to work on a PR to implement this idea? |
|||
| msg390801 - (view) | Author: Eli Schwartz (eschwartz) * | Date: 2021-04-11 22:17 | |
I started to look into this, but it seems like I'd need a bit of duplication to handle byte compiling the installed files in two different Makefile targets. The alternatives are templating, automake style, or GNU make'isms like the $(call) function, or possibly running `$(MAKE) bytecompile` to do all byte-compilation in a shareable submake. Do any of these sound good? Any other thoughts? |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:41 | admin | set | github: 87448 |
| 2021-04-11 22:17:47 | eschwartz | set | messages: + msg390801 |
| 2021-02-21 11:09:23 | vstinner | set | nosy:
+ vstinner messages: + msg387453 |
| 2021-02-21 04:49:05 | eschwartz | create | |