Skip to content

Do not include tests in Astropy wheels (reduce wheel size for AWS Lambda) #16152

Open

Description

@lpsinger

What is the problem this feature will solve?

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

Activity

  1. neutrinoceros commented on Mar 4, 2024

    @neutrinoceros
    Contributor

    It would be useful to compare these numbers against the size of astropy's dependencies in the same context.

  2. lpsinger commented on Mar 4, 2024

    @lpsinger
    ContributorAuthor

    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.

  3. pllim commented on Mar 4, 2024

    @pllim
    Member

    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? 🤔

  4. 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
  5. lpsinger commented on Mar 4, 2024

    @lpsinger
    ContributorAuthor

    Sure... I have been out of the loop of dev telecons. When are they?

  6. lpsinger commented on Mar 4, 2024

    @lpsinger
    ContributorAuthor

    I can't make it to this Thursday, but I can try for the next one.

  7. astrofrog commented on Mar 5, 2024

    @astrofrog
    Member

    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()?

  8. WilliamJamieson commented on Mar 6, 2024

    @WilliamJamieson
    Contributor

    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.

  9. MridulS commented on Mar 6, 2024

    @MridulS
    Contributor

    +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.

  10. pllim commented on Mar 6, 2024

    @pllim
    Member

    Now it is starting to sound like y'all wanna kill the test runner altogether!

    test = TestRunner.make_test_runner_in(__path__[0])

    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.

  11. namurphy commented on Mar 7, 2024

    @namurphy
    Contributor

    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...

    from setuptools import setup, find_packages
    
    setup(..., packages=find_packages(exclude=["tests"]))
  12. 20 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions