PlasmaPy wants to be Astropy for plasma science

The stated ambition is an Astropy for plasma science

PlasmaPy describes itself as an open source, community-developed Python package for plasma research and education, and then says what it is trying to be: for plasma science what Astropy is for astronomy. That is a collection of functionality commonly needed by plasma scientists and researchers globally, running within and leveraging the open source scientific Python ecosystem.

The comparison is more than a slogan, because the dependency list follows it. `astropy` is a required dependency with a range of 6.1.3 up to but not including 8, and the project badge says it is powered by Astropy. Alongside that sit `scipy`, `numpy`, `pandas`, `matplotlib`, `mpmath`, `h5py`, `lmfit`, `requests` and `tqdm`, which is the standard scientific Python stack rather than something exotic.

The scope implied by the repository topics is wide: plasma physics, fusion, heliophysics, high energy density physics, atomic physics, solar and space physics, and particles. That breadth is the reason a single shared package is worth attempting at all, since a plasma calculation that one lab writes for itself is usually written again in the next lab.

The package is published on PyPI and on conda-forge, the documentation lives at `docs.plasmapy.org`, and there is an example gallery of Jupyter notebooks that the project points people to when they want to see what the thing can do before reading the API reference.

Two install commands, and a documentation page for the rest

Installation is a pip install, and the project gives the command for each platform. On macOS or Linux:

python -m pip install plasmapy

And on Windows through PowerShell:

py -3.14 -m pip install plasmapy

The project notes that on some systems you may need to spell out the Python version, using `python3` or `python3.14` instead of `python`, and that the `3.14` in the Windows command can be replaced by any version of Python that is installed and supported by PlasmaPy. So the interpreter version is a first-class part of the install, not an afterthought.

The full instructions live in the online documentation, which is linked as the authoritative source for installation. The reasoning for that split is practical rather than cautious: the plain pip command covers the common case, and the documentation page covers conda environments, virtual environments and the platform-specific cases that do not fit in a one line snippet.

The package is also installed from a conda-forge channel, which matters for people working in the wider scientific Python environment where mixing pip and conda installs is a known source of broken environments. Choosing the conda-forge package rather than the PyPI one is usually the cleaner route for a research workstation.

SPEC 0 and a Python 3.12 floor shape the dependency policy

The manifest is where the project's engineering policy is visible. The build backend is setuptools with `setuptools-scm`, so the version is derived from the repository rather than typed in, and the package requires Python 3.12 or newer with classifiers listed for 3.12 through 3.15.

The comments in the manifest explain the reasoning in the maintainers' own terms. SPEC 0 recommends that projects drop support for Python versions three years after their initial release, and the metadata carries a SPEC 0 badge for minimum supported dependencies. The upper bounds on dependency versions are described as temporary, on the grounds that hard caps make it harder to resolve environments when PlasmaPy is installed alongside other packages, with the heliopythoniverse named as an example of that neighbourhood.

The dependency list itself is conventional: astropy, h5py, lmfit, matplotlib, mpmath, numpy, packaging, pandas, pytest pinned to 9.0.3, requests, scipy and tqdm.

That last pin is a small signal about how the project works. A test framework pinned to an exact version in the runtime dependency list is unusual, and it reflects a culture where the test suite is treated as part of the product rather than as a development detail.

The repository is set up for that culture. There is a `noxfile.py` for task automation, a `uv.lock` with pinned environments, a `.pre-commit-config.yaml`, a `conftest.py` at the root, a `tests/` directory, `type_stubs/` for type checking, a `changelog/` directory, and a `docs/` tree that is built on Read the Docs. Several of the workflow badges point at upstream checks, testing the package against other projects' dependency sets.

Calendar versioning and a heavy continuous integration setup

The release scheme is calendar versioning: v2025.8.0 in August 2025, v2025.10.0 in October 2025, and v2026.2.0 in February 2026. For a research package, that is a sensible choice, because it tells a reader at a glance how old a result was computed and it removes the question of which feature landed in which minor version.

The repository is not archived and the last push was on 2026-10-20, so the code is being worked on continuously, with the tagged releases following the calendar.

The continuous integration badges show the shape of the checking. There is a standard CI workflow, a separate comprehensive tests workflow, an upstream tests workflow and an upstream docs workflow, plus pre-commit.ci, Codecov coverage and a Read the Docs build status. Building the docs as part of the same pipeline as the code is what stops the API reference from drifting away from the implementation.

There is also a `CITATION.cff` file and a request that users cite the software. The project explains the reasoning directly, that citing software used in research gives credit to its authors, promotes open science and reproducibility, and helps open source projects show funding agencies that continued development should be supported. Prior releases and other resources are archived on the PlasmaPy community's Zenodo record, with a DOI attached.

Where PlasmaPy is the wrong tool, and how contributions are handled

The first limit is dependency weight. If you need one plasma formula in a script that has to run somewhere with a minimal environment, installing astropy, scipy, numpy, pandas and matplotlib to get it is a poor trade. A single well-tested function copied into your own code, with a citation, may serve you better.

The second is that a general package is not a specialist code. If your work depends on a particular simulation or particle-in-cell tool, that tool has its own conventions, its own data formats and its own community around it. PlasmaPy's value is in the common layer, not in replacing the specialised thing you already rely on.

On the contribution side, the project is candid in a way that is worth reading before you send a pull request. There is a note that due to the limited availability of code reviewers, pull requests are likely to experience delayed code reviews. For a volunteer-run community project that is an honest statement rather than a complaint, but it does mean that a contribution has a queue in front of it, and that the maintainers' review capacity, not the quality of a patch, is the limiting factor.

The rest of the community infrastructure is conventional and well signposted: a contributor guide, a code of conduct, good first issues, community meetings with a public calendar, a low-volume mailing list, GitHub discussions, a contact address, and a private route for reporting a security vulnerability. Development has been supported in part by the National Science Foundation, NASA, the Department of Energy and the Smithsonian Institution, and the licence is a 3-clause BSD licence with added protections against software patents, recorded in the `PATENT.md` and `licenses/` files in the repository.

Editorial conclusion

PlasmaPy fits a plasma scientist, a fusion or heliophysics student, or an educator who wants the common plasma calculations in one maintained library instead of a private notebook of copied formulas. It does not fit a project that needs a narrow numerical routine today and wants no dependencies, since the install pulls astropy, scipy, numpy, pandas and matplotlib, and it does not fit a domain where a specific simulation code is the right answer. Check three things before adopting it: that your Python is 3.12 or newer, since the manifest requires it and lists support up to 3.15, that the functions you need are actually in the package rather than in a specialised code you were planning to use anyway, and which release you pin, since the line is calendar-versioned with v2026.2.0 from 2026-02-21 and the last push on 2026-10-20.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. PlasmaPy/PlasmaPy on GitHub
3. Project website
4. README
5. Releases