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) * (Python committer) | 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 | |