# nipype wraps a pile of neuroimaging binaries in one Python interface

> nipype is a Python project that gives AFNI, FSL, FreeSurfer, SPM and other neuroimaging packages a uniform interface and lets their steps be wired into a single workflow graph. It orchestrates tools; it does not reimplement the science behind them.

**nipy/nipype** — Workflows and interfaces for neuroimaging packages

- Repository: https://github.com/nipy/nipype
- Website: https://nipype.readthedocs.org/en/latest/
- Stars: 835 · Forks: 541
- Language: Python
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/nipy-nipype

## The problem is not the algorithms, it is the interface sprawl

Neuroimaging analysis is served by a long list of specialised applications, each with its own command line conventions, its own file formats, its own idea of what a directory should look like. The README states the problem plainly: users have an opportunity to analyze data with a variety of different algorithms, and the result is a heterogeneous collection of specialised applications without transparent interoperability or a uniform operating interface.

nipype addresses that gap from Python. It is an open source, community developed initiative under the NiPy umbrella, and its job is to provide a uniform interface to existing neuroimaging software so that those packages can interact inside one workflow. The list of tools it wraps is long: AFNI, ANTS, BRAINS, BrainSuite, Camino, FreeSurfer, FSL, MNE, MRtrix, Nipy, Slicer and SPM.

The stated benefits are about reuse and reproducibility rather than about speed of computation. You can combine processing steps from different packages, reuse common steps from old workflows when writing new ones, run the work in parallel on many cores or machines, make research easier to reproduce, and share the workflow with the community. It also lowers the learning curve for moving between packages, which is the part that hurts most when a student inherits a lab's scripts.

Note the scope, though. nipype wraps those programs; it does not contain their algorithms, and it does not replace them.

## Interfaces and workflows assembled as a graph, not a shell script

The mechanism is a Python object model that sits between your code and the external binaries. Rather than writing a shell script that shells out and parses stdout, you construct an interface for a tool, set its inputs as named properties, and the library handles invocation and file handling.

The workflow layer is where the dependency list starts to explain itself. networkx and pydot appear as required dependencies, which is what you would expect from a system that keeps its processing steps as nodes and edges in a directed graph. simplejson handles the serialisation of that graph and of workflow definitions, so a pipeline can be stored, reloaded, and rerun rather than retyped.

Provenance is a first-class concern here. The prov and rdflib dependencies point to a provenance model that records where data came from and what was done to it, which is the mechanism behind the README claim that research becomes easily reproducible and shareable. Whether a particular interface emits detailed provenance for a particular tool is a question the API documentation answers for that tool, not for the framework as a whole.

Dependencies such as filelock, which is required, sit alongside these: they matter precisely because multiple nodes of a workflow can run at once.

## Installing on Python 3.12 and choosing the extras you actually need

The current release line requires a modern interpreter. The project metadata declares:

```yaml
requires-python = ">=3.12"
```

The classifiers list Python 3.12, 3.13 and 3.14, and the required dependencies are correspondingly current, with numpy>=2.2.0, scipy>=1.15.0, nibabel>=5.3 and networkx>=3.4 among them. A base install is not lightweight, so plan disk space and install time accordingly.

Distribution points are PyPI and conda-forge, and the README links both. Conda is the friendlier choice on a workstation that will also carry AFNI or FSL, since it keeps the whole toolchain in one environment manager rather than splitting it across pip and system packages.

The extras are where the real choices sit. They are optional groups rather than a single dependency list:

```yaml
nipy = ["nitime", "nilearn>=0.11.0", "dipy", "nipy", "matplotlib"]
pybids = ["pybids>=0.18.0"]
data = ["datalad"]
```

The nipy extra pulls the scientific Python stack for people who want to stay inside Python. The pybids extra is for BIDS datasets. The data extra brings datalad. Others exist for ssh remote access via paramiko, citation tracking via duecredit, profiling via psutil, and code formatting via black. Install the extras you need, not the lot.

Development happens from a checkout, and the Makefile drives it:

```bash
$(PYTHON) -m pytest --doctest-modules nipype
```

The Makefile also provides targets for building a source distribution, building an egg, uploading to PyPI, generating Dockerfiles, and cleaning build artefacts.

## The Python 2 era is closed, and the README still explains how to stay in it

The README carries a Python 2 statement that is worth reading as a policy document rather than as current advice. It states that Python 2.7 reaches end of life in January 2020 and that many projects are removing support in advance, which makes supporting Python 2 increasingly untenable even where it might be wanted.

The escape hatch is spelled out. The final series carrying 2.7 support is 1.3.x, and the README tells users who cannot move to Python 3 to pin the dependency:

```text
nipype<1.4
```

Bug fixes are still accepted against the maint/1.3.x branch, so a stuck organisation is not left with a frozen tree.

This creates a second practical decision for anyone adopting nipype today. You are choosing between a current release that requires Python 3.12 or newer and a legacy 1.3.x line that still works on the interpreter your legacy codebase runs on but receives only maintenance fixes. The current release numbers make the gap obvious: 1.9.2 and 1.10.0 both shipped on 2025-03-19, and 1.11.0 followed on 2026-03-02.

Support for questions goes to NeuroStars with a nipype tag, and development discussion happens on the neuroimaging mailing list with nipype in the subject line.

## The Makefile still builds with setup.py while the package builds with hatchling

Look closely at the build configuration and you find an inconsistency that will confuse anyone working from a checkout. The package metadata declares a modern build system:

```toml
[build-system]
requires = ["hatchling", "hatch-vcs"]
build-backend = "hatchling.build"
```

The Makefile, meanwhile, still calls setup.py directly for its distribution targets:

```bash
$(PYTHON) setup.py sdist
```

The Makefile comment explains the history, referring to pushing files to sourceforge with rsync, which dates that target to an era before the current packaging layout.

There is a second consequence hiding in the build-system block. The project version is marked as dynamic and resolved by hatch-vcs, which derives the version from the version control history. A plain source copy without the git metadata therefore does not carry a usable version string, and the README's own distribution story is the one to follow: install from PyPI or from conda-forge rather than from an unpacked tarball.

This is a small thing, but it is the kind of detail that costs an afternoon when it goes unnoticed, and it is a fair argument for treating the Makefile as a development convenience rather than the supported packaging path.

## Where nipype is the wrong tool for the job

The clearest limitation is the one the project states about itself. nipype provides interfaces to external software, so the external software has to exist. Installing nipype does not install AFNI, FSL, FreeSurfer or SPM, and the interfaces cannot produce results that the underlying binaries cannot. For a lab standardising on one package, a plain command line script may be less machinery than nipype asks for.

The second limitation is that the value depends on breadth. An interface only exists for the tools the project has wrapped, and the quality of the wrapper is not uniform. Before committing, check the API documentation for the specific tool and the specific interface you need rather than assuming coverage.

The third is the dependency floor. Python 3.12 or newer with numpy 2.2 and scipy 1.15 is a high bar for shared HPC clusters and imaging centres, whose system Python is often older and pinned. The 1.3.x line exists for exactly that reason, but it means your workflow code and your colleagues' workflow code may sit on different API generations.

The fourth is the interface between science and framework. Because the framework's job is to call other people's tools, a change in a tool's command line or output format is a nipype maintenance question as much as a tool maintenance question. Pin your tool versions.

## Releases, versioning and the licence question left open

The repository is not archived and the last push was on 2026-10-19, so the codebase is still moving. The release cadence of recent versions is irregular rather than fixed: 1.9.2 and 1.10.0 both appeared on 2025-03-19, and 1.11.0 on 2026-03-02. Read that as a project with substantial work between releases rather than one that ships on a schedule, and plan to test a version bump rather than absorb it automatically.

Versioning is tied to git tags through hatch-vcs, so the number on PyPI corresponds to a tag in the repository. That is a plus for reproducibility, since the tag identifies the exact source state, and the project publishes a citable DOI through Zenodo at 10.5281/zenodo.596855.

The licence needs a sentence of care. The package metadata declares:

```toml
license = "Apache-2.0"
```

and the classifiers list the Apache Software License. The repository, however, carries a LICENSE file that GitHub does not classify as a standard licence. The two statements are not necessarily in conflict, since a distribution may ship a different notice than the classifier assumes, but they are close enough that anyone shipping nipype inside a product should read LICENSE rather than trust the metadata field.

Continuous integration runs on CircleCI and the project tracks coverage through codecov, and the repository also carries a Vagrantfile and a docker directory, which give you another route to a fixed environment.

## Conclusion

Researchers who already use several neuroimaging packages and want one scriptable, traceable pipeline should adopt nipype, and they should expect to install the underlying tools separately because the interfaces only wrap what is already on the machine. Teams that want a single package to do the analysis, or that are pinned to Python versions below 3.12, will find the dependency floor and the python version requirement of the current release a hard stop. Before adopting, check that each interface you need exists for the tool version you have installed, and read the LICENSE file, because the package metadata declares Apache-2.0 while the repository licence is classified separately.

## FAQ

### What Python version does the current nipype release require?

The project metadata sets requires-python to >=3.12, and the classifiers list Python 3.12, 3.13 and 3.14. The last series with Python 2.7 support is 1.3.x, which users who cannot move to Python 3 should pin with nipype<1.4.

### Does installing nipype also install AFNI, FSL or FreeSurfer?

No. Nipype provides a uniform interface to existing neuroimaging software, so those packages have to be installed separately on the machine. The tools it wraps include AFNI, ANTS, BRAINS, BrainSuite, Camino, FreeSurfer, FSL, MNE, MRtrix, Nipy, Slicer and SPM.

### Where is nipype published and how do I install it?

Nipype is published on PyPI and on conda-forge, and the README links both. The package is built with hatchling and hatch-vcs, and the version is resolved from the version control history, so installing from PyPI or conda-forge is more reliable than installing from an unpacked source copy.

## Sources

- [Issues](https://github.com/nipy/nipype/issues)
- [nipy/nipype on GitHub](https://github.com/nipy/nipype)
- [Project website](https://nipype.readthedocs.org/en/latest/)
- [README](https://github.com/nipy/nipype/blob/master/README.md)
- [Releases](https://github.com/nipy/nipype/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nipy-nipype