Limiting test data distributed within astroquery
- Dominant language
- Python
- Stars
- 791
- Forks
- 451
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 4
Description
I'm working with JupyterLite, where I'd like to use astroquery. Performance for starting a JupyterLite kernel depends on the memory footprint of the dependencies.
The uncompressed size of astroquery is 28 MB. That’s smaller than astropy (45 MB), but similar to numpy (32 MB), botocore (25M), and jupyterlab (22 MB). I wonder if we could bring that number down.
I'm looking within `lib/python3.13/site-packages/astroquery` and running `du -hs * | sort -hr` to check the sizes of each module. The top three, accounting for more than half of the size of astroquery, are:
```
8.4M esa
3.5M ipac
2.8M mast
```
### Breakdown by submodule
#### ESA
```
5.9M esa/integral/tests
1.0M esa/hubble/tests
252K esa/euclid/tests
```
70% of ESA module’s weight is in `astroquery/esa/integral/tests/data`, which has two test files, totaling 5.8 MB.
There are many subdirs within `esa` with much smaller sizes; note the big difference between the sizes of the last two.
#### ipac
```
952K ipac/nexsci/nasa_exoplanet_archive/tests
880K ipac/irsa/tests/data
408K ipac/irsa/irsa_dust/tests
```
#### mast
```
2.3M mast/tests
```
What can we do to limit astroquery's footprint?
Contributor guide
Research direction
Start by reproducing the size breakdown with `du -hs * | sort -hr` under `lib/python3.13/site-packages/astroquery`, then inspect the listed `esa`, `ipac`, and `mast` test-data directories. Compare how these files enter the installed package and determine a maintainable way to reduce the footprint without breaking tests. Done means the package is smaller while the relevant test suites and distribution checks still pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100