COBRApy: constraint-based metabolic modelling in Python

What constraint-based modelling is actually for

The README explains the domain before it explains the software, and that order matters. COBRA methods are widely used for genome-scale modelling of metabolic networks in both prokaryotes and eukaryotes, and the whole field rests on a simple idea with heavy consequences. A metabolic model is a stoichiometric description of a cell, a set of reactions with mass balances, and the organism's growth objective is not written down, it is inferred. The model is a linear program, and the answer to what the cell can do is whatever set of fluxes satisfies the balances and maximises the objective. That formulation is what makes genome scale questions answerable, because the search space is combinatorial but the optimisation is not. COBRApy is the package that gives Python access to that machinery, and its stated aim is to provide useful, efficient infrastructure for four things, creating and managing metabolic models, accessing popular solvers, analysing models with methods such as FVA, FBA, pFBA and MOMA, and inspecting models to draw conclusions about gene essentiality and the consequences of knock-outs. The audience is a computational biologist or a bioengineer who has a model file and a question about it.

The method set: FBA, FVA, pFBA, MOMA and knock-outs

The analysis methods listed in the README are the reason most people end up here, and it is worth knowing what each one changes about the problem. Flux balance analysis is the base case, a linear program that maximises the objective subject to the mass balances. Flux variability analysis asks the complementary question, what range of fluxes is consistent with the constraints, and the answer is a polytope that tells you which reactions are rigid and which are free. Parsimonious flux balance analysis adds a second objective that minimises the total flux used, which breaks the degeneracy that plain FBA has when many flux distributions share the optimal value, and MOMA is the minimum or minimum adjustment approach that instead looks for the smallest set of reaction changes closest to the current state. On top of those, gene deletion analysis asks what happens to growth if each gene, and therefore each reaction, is removed, which is how essentiality is computed. The second goal in the README is to inspect models and draw conclusions on gene essentiality and to test the consequences of knock-outs, and that is the workhorse use case for a strain engineering project, because it narrows a long list of candidate targets before anyone touches a pipette.

Models and solvers as objects you can pass around

Two abstractions do the work in this package and they are what the interoperability story rests on. The first is the model object, which holds the metabolites, the reactions, the genes, the objective and the bounds, and which can be read from and written to the SBML formats the ecosystem uses. The second is the solver, which the README lists as a separate infrastructure goal, accessing popular solvers. Keeping them apart is what lets a research group swap a solver, or a linear programming backend, without rewriting the analysis code, and it is why the package can be a layer under other tools rather than the tool itself. The repository layout supports that reading. The source lives under src, there is a separate tests directory, a benchmarks directory, a documentation_builder directory, release-notes directories, and a tox.ini for running the test matrix in different environments, alongside a pre-commit configuration and a separate readthedocs configuration. The default branch is devel rather than master, and the published versions are moving in small increments, with 0.32.0 and 0.32.1 both published in August 2026 and 0.31.1 earlier in the year.

The stated goal: infrastructure that other packages reuse

The README is unusually explicit about what the project wants to be, and this is the sentence that tells you whether to adopt it. The goal is for COBRApy to be useful on its own, and to be the natural choice of infrastructure for developers who want to build new COBRA related Python packages, for example for visualization, strain-design and data driven analysis. The argument is that by re-using the same classes and design principles, new methods become both easier to implement and easier to use, which brings the power of COBRA to more researchers. That is a different ambition from a reference implementation, and it has consequences for the design. The model and reaction classes are meant to be extended and shared, the analysis methods are meant to compose, and a third party package that reimplements the same data structures would break the very thing the project is selling. The topics list is consistent with that, with strain-engineering, cell-design, sbml, sbml-simulation, flux and metabolic-models all present, and the documentation links a page for downloading the docs as well as the browsable version, which tells you the project expects offline use as well as online.

Installing from PyPI, and the extra for MATLAB models

The installation section is short, and the recommendation to work inside a virtual environment comes first.

    pip install cobra

The package is published on PyPI under the name cobra, and the README notes that for further information you should follow the detailed installation instructions in the INSTALL.rst file at the root of the repository. That file matters, because a metabolic modelling stack is more than the Python package. It pulls in a linear programming backend, and the solver you end up using is a decision about the kind of model and the size of the problem, not something the README can answer in two lines. There is one extra worth knowing about. If you want to load MATLAB models, you need additional dependencies, installed as an array extra.

    pip install cobra[array]

The setup metadata in the repository is also worth a glance, because it shows the state of the floor. The build uses setuptools with wheel, the formatting is handled by Black with a line length of 88 and a target of Python 3.8, and the setup.py file still carries a warning for anyone on Python older than 3.6, saying that earlier versions may be functional if you can manage the dependencies yourself. The version string is passed as an argument to setup, with 0.32.1 as the current value.

Support that runs on volunteers, and where to ask

The README's guidance on where to ask questions is worth following carefully, because it tells you how the project expects to be used. The Google Group is the recommended place for help, and the reasoning is given, that a well formulated question with sufficient detail is much more likely to get a good answer quickly, with a pointer to the Stack Overflow guidelines on how to ask. For quicker exchanges there is Gitter, described as faster for questions and discussions, and the README adds the caveat that answers are provided on a volunteer basis. Two practical consequences. First, this is a research community rather than a support desk, so an unanswered question is not a bug report, and the burden of writing a good one is on you. Second, a project that positions itself as shared infrastructure wants the questions asked in public, because a good answer on the group becomes reusable documentation for the next person. The project also asks for citations in scientific publications, pointing at the doi for the original paper, and the repository carries a contributor covenant badge and a code of conduct file in the .github directory, alongside the contributing guidelines the README links to.

Dual licensing, the release cadence and the branches

The licence is the one thing in the README that is genuinely unusual, and it is stated twice. The COBRApy source is released under both the GPL and the LGPL, version 2 or later, and you may choose which of the two you use the software under. For a scientific package that is a sensible arrangement, because the copyleft of the GPL protects the commons while the LGPL allows it to be linked into software under other terms, and the choice lets an organisation that is required to ship proprietary code pick the licence that fits. The disclaimer is the standard one, that the program is distributed in the hope that it will be useful but without any warranty, and the documentation badge points at the LGPL page. On maintenance, the picture is one of a project with steady work rather than bursts. The last push was on 2026-10-12, the default branch is devel, the recent published versions are 0.31.1 from 2026-03-26, 0.32.0 from 2026-08-10 and 0.32.1 from 2026-08-11, and the repository has no GitHub releases, so the PyPI version is the thing to pin. The Zenodo DOI badge in the readme is there so that a specific version can be cited, which is the practice to follow if your results depend on a particular release.

Editorial conclusion

Adopt COBRApy if you work with genome scale metabolic models and want the standard Python object model for them, because the value is interoperability as much as the analysis methods, and the project explicitly aims to be the infrastructure other packages build on. It does not fit a project that needs its own solver, since the package is built around access to popular solvers rather than providing one, and it does not fit a workflow that needs long term support guarantees, because the project publishes a rolling set of minor versions with a development branch as the default. Before you build on it, read INSTALL.rst for the solver setup, pin the version you test against, and cite the paper the README asks for, since the project asks users in publications to cite doi:10.1186/1752-0509-7-74.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. opencobra/cobrapy on GitHub
3. Project website
4. README
5. Releases