astropy: A Community Python Library for Astronomy

[pllim]

Submitting Author: @pllim All current maintainers: (I need help with this. We have hundreds of contributors. Do you just want the names from https://www.astropy.org/team ? Do you have a max number limit? Or should I put a blanket team name here? What is the expected order?) Package Name: astropy One-Line Description of Package: A Community Python Library for Astronomy Repository Link: https://github.com/astropy/astropy Version submitted: 7.1.0 EiC: @yeelauren Editor: @crhea93
Reviewer 1: @adityapt
Reviewer 2: @egbdfx
Archive: TBD JOSS DOI: TBD Version accepted: TBD Date accepted (month/day/year): TBD

---

Code of Conduct & Commitment to Maintain Package

• [x] I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package after should it be accepted.
• [x] I have read and will commit to package maintenance after the review as per the pyOpenSci Policies Guidelines.

Description

• Include a brief paragraph describing what your package does:

The Astropy Project is a community effort to develop a core package for astronomy using the Python programming language and improve usability, interoperability, and collaboration between astronomy Python packages. The core astropy package contains functionality aimed at professional astronomers and astrophysicists, but may be useful to anyone developing astronomy software. The Astropy Project also includes "affiliated packages," Python packages that are not necessarily developed by the core development team, but share the goals of Astropy, and often build from the core package's code and infrastructure.

Scope

• Please indicate which category or categories. Check out our package scope page to learn more about our scope. (If you are unsure of which category you fit, we suggest you make a pre-submission inquiry):

  • [x] Data retrieval
  • [x] Data extraction
  • [x] Data processing/munging
  • [ ] Data deposition
  • [ ] Data validation and testing
  • [x] Data visualization[^1]
  • [ ] Workflow automation
  • [ ] Citation management and bibliometrics
  • [x] Scientific software wrappers (wcslib?)
  • [ ] Database interoperability

Domain Specific

• [ ] Geospatial
• [ ] Education

Community Partnerships

If your package is associated with an existing community please check below:

• [x] Astropy:My package adheres to Astropy community standards
• [ ] Pangeo: My package adheres to the Pangeo standards listed in the pyOpenSci peer review guidebook

[^1]: Please fill out a pre-submission inquiry before submitting a data visualization package.

• For all submissions, explain how and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):

  • Who is the target audience and what are scientific applications of this package? Target audience are people involved in astrophysics or astronomy who use Python. astropy is the core library that the Astropy Project builds upon.

  • Are there other Python packages that accomplish the same thing? If so, how does yours differ? No.

  • If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

• [x] does not violate the Terms of Service of any service it interacts with.
• [x] uses an OSI approved license.
• [x] contains a README with instructions for installing the development version.
• [ ] includes documentation with examples for all functions.
• [x] contains a tutorial with examples of its essential functions and uses.
• [x] has a test suite.
• [x] has continuous integration setup, such as GitHub Actions CircleCI, and/or others.

Publication Options

• [x] Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Checks

• [x] The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
• [x] The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
• [ ] The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/. (I can add that later; out of time today.)
• [x] The package is deposited in a long-term repository with the DOI: https://zenodo.org/records/15473616

Note: JOSS accepts our review as theirs. You will NOT need to go through another full review. JOSS will only review your paper.md file. Be sure to link to this pyOpenSci issue when a JOSS issue is opened for your package. Also be sure to tell the JOSS editor that this is a pyOpenSci reviewed package once you reach this step.

Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?

This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.

• [x] Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.

Confirm each of the following by checking the box.

• [x] I have read the author guide.
• [x] I expect to maintain this package for at least 2 years and can help find a replacement for the maintainer (team) if needed.

Please fill out our survey

• [ ] Last but not least please fill out our pre-review survey. This helps us track submission and improve our peer review process. We will also ask our reviewers and editors to fill this out. (I can fill this out later; out of time today.)

P.S. Have feedback/comments about our review process? Leave a comment here

Editor and Review Templates

The editor template can be found here.

The review template can be found here.

[pllim]

Note to self: sunpy did it here https://github.com/pyOpenSci/software-submission/issues/147

Side discussion: https://github.com/pyOpenSci/software-submission/pull/252

[lwasser]

This review is on pause while the community decides if they want to move forward! @eliotwrobson just letting you know !! i'll add a label

[eteq]

@lwasser - I think we want to move ahead with this review but just wanted to confirm a few things:

This package is of course a much larger package than most pyOpenSci reviews. We (the Astropy Coordination Committee) are guessing that the expected level of review is comparable to what sunpy got in #147 - i.e., a bit more high-level of a review and not e.g. expecting the reviewer to confirm every single public function has complete docstrings. Assuming that's what you're thinking as well we are happy to have the process continue. But we do not want to create undue burden on some poor reviewer or editor (nor on our own maintainers given they aren't necessarily all signed up for this). So please advise, if that sounds right to you we are happy to move forward with this.

[lwasser]

@eteq, my apologies for the delay in responding here. I took a vacation!

In terms of moving forward, yes, we would definitely expect that the Astropy review would be more high-level and similar to what SunPy went through. I think the next step will be to figure out who can lead this as editor. Will @dhomeier and @hamogu have a conflict of interest (I am not familiar with who works on what parts of Astropy!). cc: @pllim

Let's figure that out together and then we can begin to move things forward!

[hamogu]

I think this is best served by an editor other than me and @dhomeier . I'm not too worried about a conflict of interest, but the package is just so big and so established, that the most beneficial would be a really outside perspective, both for the editor and the reviewers. Every potential reviewer within the astropy community has worked on that package themselves in some form other the years (weather through code contributions or community discussions or some other means) and the packaging standards, layout, testing, docs etc., are what is to be considered the standard that other atrocities package should looks for.

So, if this review has any use, I think it's going to be that of an outside perspective. On the other hand, no specific astronomy skills are needed - we don't expect the reviewer to scrutinize e.g. how tile-compressed fits arrays with BZERO metadata are handled or how the redshift and distance of a galaxy depend on the exact value of the Hubble constant - those things are vetted carefully within the community already.

[pllim]

what is to be considered the standard that other atrocities package should looks for

If no one else, I am sure @Cadair will not be shy to point those out... 😆

[lwasser]

Ok! I think finding the right editor and reviewers will be the tricky part here. I'll sync with @eliotwrobson on how to move this one forward!!

Because most of the astro community has likely contributed to this package, perhaps we look for one reviewer who is more focused on the package and usability, and another who, if they have contributed, has made small contributions (not a maintainer). Does that sound reasonable to you all?

[pllim]

Thank you for choosing to proceed with this! Please let us know if you have questions or concerns that Astropy can assist with.

[lwasser]

Ok! @pllim @eteq and everyone here. I just posted on our Slack. We may need a new editor for this one, but I am working on moving this forward. We are currently in the middle of an EiC rotation, and our EiC is on holiday. When she returns, we will also have a bit more help in finding a new editor. More soon!

[lwasser]

Hi everyone! 👋🏻 We are close to being able to kick off the review here for Astropy. First, we will run the EiC checks, so please stay tuned for more on that. We also already have an editor lined up, @crhea93, but we need to complete EiC checks first and we are at the beginning of our EiC rotation this month..

In the meantime, I just realized - WOW, Astropy has a HUGE maintainer team. Let's discuss how to list authors/maintainers meaningfully on the pyOpenSci website. Perhaps we link to the team landing page?

I do want to ensure that everyone gets credit for their work on this. We won't be able to fit everyone on our package listing page here:

But we could include a link if the list is a certain size in our code, and then you could add as many as you wanted to (or just use the link above).

[pllim]

I think https://www.astropy.org/team is fine. No need to duplicate effort. We update the team page regularly and contributor list is updated every release.

[yeelauren]

Hey All 👋
Just catching up on the conversation here, will have EiC checks completed this week!

[yeelauren]

Hi there! Thank you for submitting your package for pyOpenSci review. Below are the basic checks that your package needs to pass to begin our review. If some of these are missing, we will ask you to work on them before the review process begins.

Please check our Python packaging guide for more information on the elements below.

• [x] Installation The package can be installed from a community repository such as PyPI (preferred), and/or a community channel on conda (e.g., conda-forge, bioconda).
  • [x] The package imports properly into a standard Python environment import package.
• [x] Fit The package meets criteria for fit and overlap.
• [x] Documentation The package has sufficient online documentation to allow us to evaluate the package's function and scope without installing the package. This includes:
  • [x] User-facing documentation that overviews how to install and start using the package.
  • [x] Short quickstart tutorials that help a user understand how to use the package and what it can do for them.
  • [x] API documentation (documentation for your code's functions, classes, methods, and attributes): this includes clearly written docstrings with variables defined using a standard docstring format.
• [x] Core GitHub repository Files
  • [x] README The package has a README.md file with a clear explanation of what the package does, instructions on how to install it, and a link to development instructions.
  • [x] Contributing File The package has a CONTRIBUTING.md file that details how to install and contribute to the package.
  • [x] Code of Conduct The package has a CODE_OF_CONDUCT.md file.
  • [x] License The package has an OSI approved license. NOTE: We prefer that you have development instructions in your documentation too.
• [x] Issue Submission Documentation All of the information is filled out in the YAML header of the issue (located at the top of the issue template).
• [x] Automated tests Package has a testing suite and is tested via a Continuous Integration service.
• [x] Repository The repository link resolves correctly.
• [x] Package overlap The package doesn't entirely overlap with the functionality of other packages that have already been submitted to pyOpenSci.
• [ ] Archive (JOSS only, may be post-review): The repository DOI resolves correctly.
• [ ] Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

Optional: Let projects know that it's a great idea for projects to have a .github repository for the project organization where they can host a commonly used LICENSE, Code of Conduct, and even a YAML file with label definitions. These items will then be automatically applied to every repository in the organization to ensure consistency (but can be customized within repos too). The SunPy project has a great example of this.

---

• [ ] Initial onboarding survey was filled out We appreciate each maintainer of the package filling out this survey individually. :raised_hands: Thank you, authors, in advance for setting aside five to ten minutes to do this. It truly helps our organization. :raised_hands:

---

---

Editor comments

👋 Astropy is in amazing shape to move on in the review process. Some minor suggestions:

• Contributing guide on github is more complete here https://github.com/astropy/astropy?tab=contributing-ov-file than on the website https://docs.astropy.org/en/stable/index_dev.html
• could you link to https://docs.astropy.org/en/latest/index_dev.html directly ?
• suggest adding code of conduct as a .md file to github from here https://www.astropy.org/code_of_conduct.html

[pllim]

Hello and thank you! Some follow-up below:

Contributing guide

https://docs.astropy.org/en/stable/index_dev.html is purposefully brief. You may notice that at the bottom, it points to https://docs.astropy.org/en/latest/index_dev.html and if you follow that link, you will notice that it is way more complete than the stable version. This is because we ran into problems of users accidentally following outdated practices because stable version only gets updated every release, while the development stuff may change in between.

could you link to ... directly?

Are you suggesting that I clear all the contents of https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md and just throw in a link to https://docs.astropy.org/en/latest/index_dev.html ? If not, please clarify.

suggest adding code of conduct as a .md file to github from here ...

I am afraid I do not understand this request. We already have https://github.com/astropy/astropy/blob/main/CODE_OF_CONDUCT.md and it does link to https://www.astropy.org/code_of_conduct.html . The latter is the canonical source, though at the moment, we are also in the midst of switching over to using NumFOCUS version (https://github.com/astropy/astropy.github.com/pull/669).

[crhea93]

Editor response to review:

---

Editor comments

Greetings @pllim! Congratulations on this monumental (and influential) package. As editor, it will be my job to find reviewers and guide them through the process. Additionally, I am here to help YOU with anything that might come up during this process. I look forward to the review!

~~I've started to reach out to potential reviewers, so hopefully the review can begin in earnest in the upcoming weeks.~~

Please fill out our pre-review survey

Before beginning your review, please fill out our pre-review survey. This helps us improve all aspects of our review and better understand our community. No personal data will be shared from this survey - it will only be used in an aggregated format by our Executive Director to improve our processes and programs.

• [x] reviewer 1 survey completed.
• [x] reviewer 2 survey completed.
• [ ] reviewer 3 (if applicable)

The following resources will help you complete your review:

1. Here is the reviewers guide. This guide contains all of the steps and information needed to complete your review.
2. Here is the review template that you will need to fill out and submit here as a comment, once your review is complete.

Please get in touch with any questions or concerns! Your review is due: December 15th, 2025

Reviewers: @adityapt, @egbdfx Due date: December 15th, 2025

[yeelauren]

Hello and thank you! Some follow-up below:

Contributing guide

https://docs.astropy.org/en/stable/index_dev.html is purposefully brief. You may notice that at the bottom, it points to https://docs.astropy.org/en/latest/index_dev.html and if you follow that link, you will notice that it is way more complete than the stable version. This is because we ran into problems of users accidentally following outdated practices because stable version only gets updated every release, while the development stuff may change in between.

could you link to ... directly?

Are you suggesting that I clear all the contents of https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md and just throw in a link to https://docs.astropy.org/en/latest/index_dev.html ? If not, please clarify.

suggest adding code of conduct as a .md file to github from here ...

I am afraid I do not understand this request. We already have https://github.com/astropy/astropy/blob/main/CODE_OF_CONDUCT.md and it does link to https://www.astropy.org/code_of_conduct.html . The latter is the canonical source, though at the moment, we are also in the midst of switching over to using NumFOCUS version (astropy/astropy.github.com#669).

Thanks for the clarification! I've updated the checklist above. For the code of conduct, I thought it was really well written, but was expecting it to be found within the GitHub repo itself. This may just be my own personal preference, though :)

[pllim]

Code of conduct -- It is shared across the project, so we want to avoid the risk of every repo having their own complete copies and then go out of sync. Hopefully the way we do it right now is not a deal breaker for review.

Contributing guide -- Do you still want me to do something with https://github.com/astropy/astropy/blob/main/CONTRIBUTING.md ?

[yeelauren]

@pllim That makes sense to me - just to be clear there's no action required nor a deal breaker :)
Looking forward to the next step in the process soon 🥳

[adityapt]

Thanks @crhea93 ! I am going to create my review checklist here and will update it as I keep reveiwing the package.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• [x] As the reviewer, I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• [x] A statement of need clearly stating problems the software is designed to solve and its target audience in the README file.
• [x] Installation instructions: for the development version of the package and any non-standard dependencies in README.
• [ ] Short quickstart tutorials demonstrating significant functionality that successfully runs locally.
• [ ] Function Documentation: for all user-facing functions.
• [ ] Examples for all user-facing functions.
• [x] Community guidelines including contribution guidelines in the README or CONTRIBUTING.
• [x] Metadata including author(s), author e-mail(s), a URL, and any other relevant metadata, for example, in a pyproject.toml file or elsewhere.

Readme file requirements The package meets the readme requirements below:

• [x] Package has a README.md file in the root directory.

The README should include, from top to bottom:

• [x] The package name
• [x] Badges for:
  • [x] Continuous integration and test coverage,
  • [x] Docs building (if you have a documentation website),
  • [x] Python versions supported,
  • [x] Current package version (on PyPI / Conda).

NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be wider than high. A badge for pyOpenSci peer review will be provided when the package is accepted.

• [x] Short description of package goals.
• [x] Package installation instructions
• [x] Any additional setup required to use the package (authentication tokens, etc.)
• [ ] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file.
  • [ ] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
• [x] Link to your documentation website.
• [ ] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
• [x] Citation information

Usability

Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole. The package structure should follow the general community best practices. In general, please consider whether:

• [x] Package documentation is clear and easy to find and use.
• [x] The need for the package is clear
• [x] All functions have documentation and associated examples for use
• [x] The package is easy to install

Functionality

• [x] Installation: Installation succeeds as documented.
• [ ] Functionality: Any functional claims of the software been confirmed.
• [ ] Performance: Any performance claims of the software been confirmed.
• [ ] Automated tests:
  • [ ] All tests pass on the reviewer's local machine for the package version submitted by the author. Ideally this should be a tagged version making it easy for reviewers to install.
  • [ ] Tests cover essential functions of the package and a reasonable range of inputs and conditions.
• [x] Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
• [ ] Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines. A few notable highlights to look at:
  • [x] Package supports modern versions of Python and not End of life versions.
  • [ ] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

For packages also submitting to JOSS

• [x] The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

• [ ] A short summary describing the high-level functionality of the software
• [ ] Authors: A list of authors with their affiliations
• [ ] A statement of need clearly stating problems the software is designed to solve and its target audience.
• [ ] References: With DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

• [ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:

---

Review Comments