Affiliated Packages#
Affiliated packages are well-maintained, open source software packages that are useful to solar physicists and integrate well with the SunPy ecosystem. To aid discoverability, all affiliated packages are listed on the SunPy website, and the SunPy project tries to advertise them at national and international conferences and workshops.
Package list#
sunpy core |
The core package for solar physics in Python.
Maintainer: The SunPy Project Version reviewed: v1.1.4 |
ndcube |
Base package for multi-dimensional (non)contiguous coordinate-aware arrays. Maintainers: The SunPy Project
Version reviewed: v1.3.2 |
drms |
Provides search capability for the JSOC DRMS server which enables complex queries of HMI, AIA and MDI data. Maintainers: The SunPy Project
Version reviewed: v0.5.7 |
sunraster |
Package designed for reading, manipulating and visualizing data taken with slit spectrograph instruments. Maintainers: The SunPy Project
Version reviewed: v0.1.2 |
sunkit-image |
Open-source toolbox for solar physics image processing. Currently an experimental library. Maintainers: The SunPy Project
Version reviewed: v0.1 |
aiapy |
Package for analyzing data from the Atmospheric Imaging Assembly (AIA) instrument onboard NASA’s Solar Dynamics Observatory spacecraft. Maintainers: Will Barnes, Nabil Freij
Version reviewed: v0.1.0 |
pfsspy |
Potential Field Source Surface modelling package. Note that this package is archived and is no longer developed. Maintainer: David Stansby
Version reviewed: v0.5.2 |
sunpy-soar |
sunpy plugin for accessing data in the Solar Orbiter Archive (SOAR). Maintainers: The SunPy Project
Version reviewed: v1.5 |
roentgen |
Package for the quantitative analysis of the interaction of energetic x-rays with matter. Maintainer: Steven Christe, Shane Maloney, Daniel Ryan
Version reviewed: v2.1 |
sunkit-instruments |
Package for instrument-specific data structures and processing in the SunPy ecosystem. Maintainers: The SunPy Project
Version reviewed: v0.3.1 |
demcmc |
Package for differential emission measure (DEM) estimation using Monte Carlo Markov chain (MCMC) methods Maintainers: David Stansby
Version reviewed: v1.1.0 |
dkist |
A package which aims to help you search, obtain and use DKIST data as part of your Python software. Maintainers: DKIST Data Center Team & Stuart Mumford
Version reviewed: v1.0.0b15 |
solarmach |
The Solar MAgnetic Connection Haus (Solar-MACH) tool is a multi-spacecraft longitudinal configuration plotter. Maintainers: Jan Gieseler
Version reviewed: v0.3.3 |
Provisional packages#
These packages are works in progress that do not yet meet the functionality criteria for an affiliated package, but are working towards it.
pyflct |
A Python wrapper for Fourier Local Correlation Tracking. Documentation, Source code Maintainers: The SunPy Project
Version reviewed: v0.2.1 |
radiospectra |
This package provides support for some types of solar radio spectrograms (e.g. CALISTO, SWAVES). Documentation, Source code Maintainers: The SunPy Project
Version reviewed: v0.3.0 |
Affiliated Package Review#
Each candidate package is reviewed by a reviewer independent of the package before it can be approved as an affiliated package.
Review Criteria#
Functionality#
Status |
Meaning |
|---|---|
|
Implements functionality relevant to a large cross-section of the solar physics community. |
|
Implements functionality which is relevant to a specific subsection of the solar physics community. |
|
This package does not implement functionality relevant to the solar physics community. |
Integration#
Status |
Meaning |
|---|---|
|
The package uses all appropriate features of the core package and affiliated package ecosystem to provide its functionality to users. It uses applicable data structures and has appropriate dependencies. |
|
Some applicable functionality of the affiliated package ecosystem may be used but further integration is possible in this package. |
|
Provides functionality which should use features such as data structures in core or other affiliated packages. i.e. provides an array and a WCS but doesn’t use ndcube, or represents physical coordinates not using sunpy.coordinates. |
Documentation#
Status |
Meaning |
|---|---|
|
Extensive online documentation, the public API has formatted docstrings describing the code’s purpose, all inputs and outputs, and includes examples. Provides high level documentation; for example, a user guide and/or an example gallery. |
|
Online documentation is either lacking in coverage or quality. For example some docstrings maybe lacking detail, or examples, or there may be minimal high level documentation. |
|
Some online documentation. The public API is documented, but may have some missing or incomplete docstrings. The documentation may be missing guides, tutorials or other high level documentation. |
|
Little to no online documentation is provided in the version control repository. No guides or tutorials. |
Testing#
Status |
Meaning |
|---|---|
|
A high quality testing suite exists which tests the individual components (e.g. functions, classes) as well as providing integration tests. Code coverage is extensive. Testing is automated and runs frequently. |
|
Unit tests of individual components (e.g. functions, classes) and integration tests, but coverage is good but not extensive. Testing is automated. |
|
Lacks tests and/or tests are not executed in a test framework (e.g. pytest). |
Duplication#
Status |
Meaning |
|---|---|
|
No code or functionality is duplicated from core, other affiliated packages, or other relevant packages. |
|
Some code or functionality duplication, some minor functionality may be duplicated from other affiliated packages, or other relevant packages. |
|
Duplicates major existing functionality in other affiliated packages. |
Community#
Status |
Meaning |
|---|---|
|
The developers actively solicit input to aid their decision-making, gather and react to community feedback, and work with other developers to improve ecosystem integration. The developers are active and engaged with the community. The package must also meet the requirements for a ‘Good’ rating. |
|
The package is developed openly. The developers have adopted a Code of Conduct compatible with SunPy’s. The developers have adopted a Code of Conduct that reflects and is not contradictory to the values in the SunPy Code of Conduct. They welcome contributions, maintain and respond to an issue tracker, and are receptive to appropriate community feedback. |
|
Code is maintained in hosted version control, but decisions are often made without considering community input or feedback. Lacks a Code of Conduct. It is not clear how to make a contribution or whether contributions are welcome. Developers do not respond to issues or an issue tracker is not used. |
Development Status#
Status |
Meaning |
|---|---|
|
Package is well maintained, contributions are responded to by the developers. API stability is prioritized and regular versioned releases are made, with any breaking changes well documented. |
|
Package is well maintained, but large API changes may be frequent due to rapid development. Contributions are responded to by the developers. Versioned releases exist and changes are documented. |
|
Package is functional but with little or no activity from the developers. The package has versioned releases and is functional. |
|
Package is no longer maintained and is not functional. |
Review Criteria and Summary#
Outcomes |
Requirements |
|---|---|
Accepted |
Must have a
green score in the |
Provisional |
After review a package is listed as provisional, as long as it is assessed to not have a red score in the “Functionality”, “Duplication” or “Community” criteria and is working towards meeting the rest of the review criteria. |
Not accepted |
A package does not currently satisfy the provisional rating. |
Open review process#
The review process for becoming a SunPy affiliated package is designed to be approachable, lightweight and open. Reviews are conducted in GitHub issues through the sunpy/sunpy.org repository.
Steps for Getting New Packages Reviewed#
If you’re not sure whether to submit your package for the affiliated package review process, you can open an issue to informally discuss your package or contact the Affiliated Package Liaison to discuss your package privately.
Open a new issue with the issue template.
The Affiliated Package Liaison will identify a reviewer independent of your package.
The reviewer evaluates the affiliated package against the review criteria.
The reviewer adds their review as a comment to the issue.
The submitting author has the right to ask for another review. In this case, the Affiliated Package Liaison will identify a new independent reviewer. This new review will be added to the same issue.
Based on the scores in each of the seven categories, the affiliated package is either accepted, given provisional status, or not accepted. In all three cases, this practically means closing the issue and ending the review process. In the last case, the reviewer provides the submitting author with feedback on how to meet the acceptance criteria with the intention of helping the submitting author achieve provisional or accepted status in the future.
If the review passed the review criteria then the submitting author or the Affiliated Package Liaison opens a pull request to add the package and its review results to the sunpy.org website, unless the submitting author withdraws the submission.
The Affiliated Package Liaison merges the pull request.
Existing Packages Review Process#
Existing affiliated packages will be reviewed once per year by the Affiliated Package Liaison to ensure the review is current. Developers may challenge a new review, which then requires the liaison to get an independent reviewer to perform the review.
Existing provisional affiliated packages will be reviewed once per year by the Affiliated Package Liaison. To pass they must not have a worse score and still be working towards meeting the rest of the review criteria.
Acknowledgements#
Sections of this page are heavily inspired by the Astropy affiliated package review process.