You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Do not include tests in Astropy wheels (reduce wheel size for AWS Lambda) #16152
Astropy is a very heavyweight dependency and is difficult to use in a serverless, space-constrained environment like AWS Lambda. When installed from wheels for Linux aarch64, the astropy directory in site-packages takes up 58 MB. Of that, the astropy/**/tests directories take up 20 MB.
Describe the desired outcome
Move the test directories out of the installed Python package, or exclude them from packaging.
Additional context
No response
Reacted by Jamie Kennea, Nick Murphy, Agriya Khetarpal and Nathaniel Starkman
Packaging for AWS is painful. When I had to do this once for a temporary project, I had to strip docs, tests, and some unused sub-packages out to get it to stay in budget.
But by doing this for AWS, the cost is that user will no longer be able to test their installation. That cost is quite high.
Maybe we can discuss this at the Coordination Meeting? 🤔
Or at least bring it up at the next dev telecon? 🤔
changed the title [-]Do not include tests in Astropy wheels[/-][+]Do not include tests in Astropy wheels (reduce wheel size for AWS Lambda)[/+]on Mar 4, 2024
user will no longer be able to test their installation
I'd be curious how often this is used. At the start of the project, before we had any proper or limited CI, it was one of the main ways we found out about platform-specific issues, but with such extensive CI coverage now, do any users installing wheels for example ever run astropy.test()?
If users really do want the ability to test their installation we could look into packaging the tests into a separate package, say astropy-tests on PyPi. Then let users know that if they want to test their installation from a PyPi wheel that they just need to install that package in addition to astropy. This being said we should consider if testing an installation like this is even necessary before pursuing this further.
Reacted by Derek Homeier, Tom, Agriya Khetarpal and Nathaniel Starkman
(Just thinking out loud here) I think many packages in the scientific python ecosystem had this in built testing due to limited CI + a need to build packages during pip install in the good ol days. With wheels today I wonder how many users would need to worry about installing a wheel and then the wheel failing the tests (we should be able to catch that quickly in our CI!). And for the user group who want to build and test I think it's fair to ask them to clone the repo/tag directly from GitHub.
Reacted by Clément Robert, Manon Marchand, Hans Moritz Günther, Nick Murphy and Agriya Khetarpal
Perhaps it is time (see #16165) but this is a long standing public API. Additionally we also encouraged downstream packages to ship their own package.test() for a while, so there are some active usage downstream. So, this really needs to be thought out and executed carefully.
My inclination would be to include tests, etc. in the source distribution (sdist) but not include tests in wheels. I looked into this a little bit and I think we could do this by including tests in MANIFEST.in (to get them in the sdist) and excluding tests in setup.py (so they're not in the wheel). Something like...
Activity
neutrinoceros commentedon Mar 4, 2024
It would be useful to compare these numbers against the size of astropy's dependencies in the same context.
lpsinger commentedon Mar 4, 2024
By far the largest dependency of Astropy is Numpy, which on Linux aarch64 takes up 63 MB. Of that, 15 MB is tests and test data.
pllim commentedon Mar 4, 2024
Packaging for AWS is painful. When I had to do this once for a temporary project, I had to strip docs, tests, and some unused sub-packages out to get it to stay in budget.
But by doing this for AWS, the cost is that user will no longer be able to test their installation. That cost is quite high.
Maybe we can discuss this at the Coordination Meeting? 🤔
Or at least bring it up at the next dev telecon? 🤔
[-]Do not include tests in Astropy wheels[/-][+]Do not include tests in Astropy wheels (reduce wheel size for AWS Lambda)[/+]lpsinger commentedon Mar 4, 2024
Sure... I have been out of the loop of dev telecons. When are they?
hamogu commentedon Mar 4, 2024
Next dev-telecon is this Thursday: https://docs.google.com/document/d/15JSFh3OMF9Iz6ov3q_xxGO_BL8hRnuse4IMUrqEIvcg/edit#heading=h.ntv4vdb5izj7
lpsinger commentedon Mar 4, 2024
I can't make it to this Thursday, but I can try for the next one.
astrofrog commentedon Mar 5, 2024
I'd be curious how often this is used. At the start of the project, before we had any proper or limited CI, it was one of the main ways we found out about platform-specific issues, but with such extensive CI coverage now, do any users installing wheels for example ever run
astropy.test()?WilliamJamieson commentedon Mar 6, 2024
If users really do want the ability to test their installation we could look into packaging the tests into a separate package, say
astropy-testson PyPi. Then let users know that if they want to test their installation from a PyPi wheel that they just need to install that package in addition toastropy. This being said we should consider if testing an installation like this is even necessary before pursuing this further.MridulS commentedon Mar 6, 2024
+1 with @astrofrog
(Just thinking out loud here) I think many packages in the scientific python ecosystem had this in built testing due to limited CI + a need to build packages during pip install in the good ol days. With wheels today I wonder how many users would need to worry about installing a wheel and then the wheel failing the tests (we should be able to catch that quickly in our CI!). And for the user group who want to build and test I think it's fair to ask them to clone the repo/tag directly from GitHub.
pllim commentedon Mar 6, 2024
Now it is starting to sound like y'all wanna kill the test runner altogether!
astropy/astropy/__init__.py
Line 137 in d32a06a
Perhaps it is time (see #16165) but this is a long standing public API. Additionally we also encouraged downstream packages to ship their own
package.test()for a while, so there are some active usage downstream. So, this really needs to be thought out and executed carefully.namurphy commentedon Mar 7, 2024
My inclination would be to include tests, etc. in the source distribution (sdist) but not include tests in wheels. I looked into this a little bit and I think we could do this by including tests in
MANIFEST.in(to get them in the sdist) and excluding tests insetup.py(so they're not in the wheel). Something like...20 remaining items
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation
Exclude tests from installation