msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.24k stars 1.21k forks source link

python: consider splitting out the stdlib tests #9908

Open GitMensch opened 2 years ago

GitMensch commented 2 years ago

Just did a fresh install and have seen that the python package ships with a big lib/python directory. Is this really needed - especially the "test" subdirectory which takes 60MB alone?

If not then it would be very reasonable to delete those in the PKGBUILD instead of shipping them; or, if it is only very seldom needed, move that out to an optional python-testlibs package.

Rechecked: the old Python Windows package I've installed over three years ago also includes lib/test (with much less content, but still). Nonetheless: Does a user of MinGW would need that?

Is it also reasonable to ship the __pycache__ folders?

lazka commented 2 years ago

If not then it would be very reasonable to delete those in the PKGBUILD instead of shipping them; or, if it is only very seldom needed, move that out to an optional python-testlibs package.

Is any other distro doing that? And which directories does this include? There are lots of test_xxx directories

Is it also reasonable to ship the __pycache__ folders?

If we wouldn't ship them then Python would create them and they wouldn't be tracked by pacman.

GitMensch commented 2 years ago

If we wouldn't ship them then Python would create them ...

sure, but only those that are actually used, and there would be some space saving for sure

... and they wouldn't be tracked by pacman.

Hm, would an uninstall then go wrong? All those __pycache__ directories would still be below a directory "created" by pacman for the package.

Is any other distro doing that?

I'm neither a python nor a distro expert so I don't know. The main question is "what do we want" and what would be the (implied) result.

And which directories does this include? There are lots of test_xxx directories

I've thought about lib/tests and everything below and all __pycache__ directories. Do we have a python expert knowing about the files there (or possibly should contact the python mailing list)?

lazka commented 2 years ago

related upstream issues:

https://bugs.python.org/issue27640

https://bugs.python.org/issue10572

GitMensch commented 2 years ago

That's interesting. So it looks 3.10 has a --disable-test-modules that we can use when updating MSYS2 python from 3.9 to 3.10 which will then also fix this issue, Hooray! (at least the test part, not sure what to do about the implications of dropping __pycache__ directories).

Is someone working on this update or any known issue with 3.10?

lazka commented 2 years ago

That's interesting. So it looks 3.10 has a --disable-test-modules that we can use when updating MSYS2 python from 3.9 to 3.10 which will then also fix this issue, Hooray! (at least the test part, not sure what to do about the implications of dropping __pycache__ directories).

If we want to remove the tests, yes (do we?). For splitting it at least defines the set of optional directories in an official way which we could split... as we still have to install them during the package build.

Is someone working on this update or any known issue with 3.10?

That's happening here: https://github.com/msys2-contrib/cpython-mingw/issues/52 Not sure when that will be ready.

lazka commented 2 years ago

Is any other distro doing that?

To answer that, Arch does: https://archlinux.org/packages/core/x86_64/python-tests/

GitMensch commented 2 years ago

In this case I think MSYS2 definitely should do the same.

GitMensch commented 2 years ago

An https://github.com/archlinux/svntogit-packages/blob/packages/python/trunk/PKGBUILD nicely shows how it is done.

lazka commented 2 years ago

Since removing the tests as a user is hard and this is "supported" upstream now this sounds good to me.

GitMensch commented 2 years ago

... and it fits perfectly well in the current "minimal size approach", too :-) Sadly I won't find the time for this myself in the next weeks, possibly months.