Long term Projects

This page will host a list of long-term projects for ChiantiPy. Project ideas should begin as issues and once they are fully-fleshed out and agreed upon, they are added to this list. Individual issues can then be created to address these projects and should be tagged with the name of the project. The project idea should include a link to the original issue (if applicable). If these projects become more formalized and the number of contributors grows, they can be converted to a project board.

Project List

Make ChiantiPy a SunPy-affiliated Package

To facilitate a more standard format for the ChiantiPy package and easier integration with other packages in the scientific Python/OpenAstronomy space, ChiantiPy should become a SunPy-affiliated package. The SunPy Enhancement Proposal (SEP) with details about affiliated packages can be found here.

Issue #11, which proposed Astropy-affiliation, spawned this project idea.

Currently ChiantiPy uses the astropy-helpers template (also used by SunPy) which has helped to streamline and standardize documentation, testing, and package structure.

A tentative list of goals for SunPy affiliation is as follows:

• Use Astropy units for all inputs and outputs
• Increase test coverage, particularly for the ion and Continuum core modules
• Improve documentation to use standard docstring formatting
• Add package to conda/conda-forge
• Address any additional requirements as specified in the SunPy SEP
• License and package the CHIANTI database. See this issue

In general, we should aim to use Astropy or SunPy functionality wherever possible to avoid code duplication. This will make the package easier to maintain and slim down the codebase so that we can focus on the science goals of ChiantiPy.

Increase Test Coverage

ChiantiPy needs some tests improved test coverage. Some simple tests might look like,

• create class instances (e.g. ion, spectrum)
• try out a variety of input arguments to each of these objects
• call some methods
• etc.

Tests were introduced in PR #61, but there is still much work to be done.

Ideally, the entire test suite gets run at each PR and passes before any PR is merged. Currently, we've implemented a minimal test suite that essentially just checks for syntax errors and covers a small range of input parameters. Ideally, we should have unit tests for each method on each class as well as all the helper functions in the tools module. Additionally, we should have integration testing between modules. This would be especially useful for testing things like the spectrum and radiativeLoss classes.

(Still need some details here about testing infrastructure)