GPy: a Gaussian process framework that still documents its 2010s install path
Gaussian processes framework in python
At a glance
- What is it?
- SheffieldML's Python Gaussian process library still carries a 2026 release line on top of a README written around Travis CI and setup.py, and the build configuration tells a more current story than the README does.
- Who is it for?
- GPy is worth a look if you want Gaussian process models in Python and expect to read the implementation rather than call a service. The releases are current, the licence is permissive, and the testing layout makes adding a model a bounded task.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 8, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A Gaussian process library with a very old README
GPy bills itself in one line as the Gaussian processes framework in Python, and the surrounding furniture matches a project that grew up inside a university lab rather than a product org. The name is pronounced g-pie, the licence badge points at BSD-3-Clause, and the citation block asks you to cite `GPy: A Gaussian process framework in python` with a year field of `since 2012`. That start date is the first hint about how long this code has been carried. The most recent tagged release is v1.14.2 from August 2026, with v1.14.0 and v1.14.1 landing two days earlier, and the last commit recorded is August 2026. Twenty-something releases later, the package is still versioned under 1.x and the README still reads like a project page from the middle of the 2010s.
The links out of the README confirm the shape. There is a homepage at sheffieldml.github.io, tutorial notebooks hosted through nbviewer, a user mailing list on the Sheffield symposia service, and separate developer documentation for the default branch and for devel at gpy.readthedocs.io. What is missing is as telling as what is there. The README never shows a single line of GPy API usage. Not one model, not one kernel, not one call to fit or predict. Everything a newcomer needs to see in order to decide whether the library fits their problem lives in the notebooks or the hosted docs, which means the README functions as a directory rather than a tutorial.
The install path the README still recommends
Installation is the most detailed part of the README, and it is also the part that has aged most visibly. GPy requires a recent scipy, stated as 1.3.0 or later, and the project strongly recommends the anaconda python distribution for that reason. The suggested sequence is to update scipy first, optionally install the system build tools, and only then run `pip install gpy`. There is a second path for people on enthought distributions that amounts to the same thing: install scipy 1.3.0 or later, then pip install GPy.
The troubleshooting section is the more honest part, because it tells you what to do when the wheels do not exist for your platform. If `pip install GPy` fails, the README proposes building the extension in place from a clone of the devel branch and running the test suite, which at least gives you a way to tell whether a failure is your environment or the package.
git clone https://github.com/SheffieldML/GPy.git
cd GPy
git checkout devel
python setup.py build_ext --inplace
pytest .Two things about that block deserve a second look. It is not legacy advice written by someone unaware of the alternatives, because the same README tells upgrading contributors to run `pip install --upgrade GPy` for pip installs and `python setup.py develop` for a development checkout. Every path documented here is a distutils-era path, and the README itself warns that `distutils/setuptools` can open a whole can of worms when compiled extensions are involved. For a library that ships Cython extensions, that warning is not a footnote.
What pyproject.toml reveals about the build
The build configuration in the repository tells a different story from the README, and the gap between them is the most useful thing here for anyone installing GPy today. `pyproject.toml` contains nothing but a build-system table. It requires setuptools and wheel, plus `numpy>=2` and `Cython>=0.29`, and it also requires `scipy>=1.3.0`. A comment in that file explains why scipy is listed at all: SciPy is what supplies `scipy.linalg.cython_blas`, which `GPy/util/choleskies_cython.pyx` cimports, so SciPy has to be present inside the PEP 517 isolated build environment rather than merely installed later in a virtualenv.
That single line of build metadata settles an argument the README leaves open. GPy is not a pure Python package that happens to optionally accelerate; a Cython file under the utilities path is compiled during the build and depends on SciPy's headers at compile time. If you have ever hit an install failure and concluded that GPy was pure Python, this is where that conclusion came from. It is also why `numpy>=2` appears at build time rather than only at run time.
So there are two descriptions of the same project. The README describes a package you install with pip after updating scipy. The build table describes one that needs a Cython toolchain, a BLAS-providing SciPy, and an isolated build environment to come together. Neither is wrong. They are just answering different questions, and the one you care about depends on whether you are a user or a packager.
Two branches and four CI services
The status table at the top of the README tracks two branches, devel and deploy, across four continuous integration services. Both rows carry a travis-ci.org badge for unit tests, an AppVeyor badge, a Coveralls badge, and a Codecov badge. That matrix is a snapshot of how Python scientific software shipped around 2016, and it is still rendered as the current state of the project.
Whether any of those services still run is not something the repository answers. Travis CI went through a long decline in open source use, AppVeyor has been quiet, and it is common now for a README to keep badges that no longer update. There is no workflow file in the tree for any of these four, so you cannot confirm from here whether devel is gated on AppVeyor or whether Codecov is still receiving coverage reports. What the table does tell you with certainty is that the project maintains two long-lived branches rather than shipping from a single trunk, and that deploy is treated as a separate concern from devel.
The default branch in the repository metadata is devel, not master. Every instruction in the README that names a branch points at devel, including the contribution flow and the build-from-source block. If you script anything against this repository, devel is the branch you want.
paramz, changelogs and the contribution path
One architectural note in the README explains that the core parameterization has been pulled out of GPy into a separate package called paramz, described as the pure gradient based model optimization. Upgrading a pip-installed GPy after that change is just `pip install --upgrade GPy`. Development checkouts need their dependencies refreshed with `python setup.py develop` run again in the installation folder, with the caveat about compiled extensions already noted. The split matters more than it looks: parameter handling is the layer every model shares, and moving it out means optimization machinery can evolve on its own release cadence.
Changes are tracked in CHANGELOG.md, and the README asks contributors to tag commits using the gitchangelog commit message format so their work actually appears there. The contribution flow is unusually explicit: fork, make changes, meet the guidelines, add tests, open a pull request against devel, and let CI run on it. New models and kernels are expected to land in the existing test frameworks, specifically `model_tests.py` and `kernel_tests.py` in the testing subfolder, rather than in a new bespoke test file. The pull request guidelines ask for PEP8 or pylint, an 80 column limit, one commit per smallest concern, and code, tests and documentation together in each functional commit.
`setup.py` is still present in the repository and still carries a BSD-3 copyright header naming the 2012 to 2014 GPy authors along with Max Zwiessele for 2014 and 2015. That header is a more honest statement of the project's age than any version number in the changelog.
Who this fits, and what you will have to read yourself
GPy is a reasonable choice when you want Gaussian process models in Python and want to read the implementation instead of calling a black box, particularly if you are willing to handle a compiled extension during installation. It has a long history, a permissive licence, an active release line as of 2026, and a testing layout that makes adding a model a bounded task rather than an open-ended one.
The costs are equally visible. You will be reading notebooks and hosted documentation rather than a README to learn the API. You may be building from source on a platform without a matching wheel, and if you do, you should read `pyproject.toml` first to see what the build needs. And you will be navigating a repository whose README still advertises CI services and install commands from an earlier decade, so treat the badges as history and the build metadata as the current truth.
If you are packaging GPy for a distribution rather than installing it into your own environment, the compiled-extension story deserves attention before you promise a wheel matrix. If you are contributing, follow the changelog format and target devel, and the project will give you a clear path.
Editorial conclusion
GPy is worth a look if you want Gaussian process models in Python and expect to read the implementation rather than call a service. The releases are current, the licence is permissive, and the testing layout makes adding a model a bounded task. The costs are on the documentation side: the README shows no API usage at all, so you will learn the library from notebooks and hosted docs, and it may send you down distutils-era install paths on a platform without a matching wheel. Verify `pyproject.toml` before you install from source, because it shows the build needs Cython, numpy>=2 and a SciPy whose `scipy.linalg.cython_blas` is importable at compile time. Then follow the contribution flow as written, target the devel branch, and put new models into the existing test frameworks.
Frequently asked questions
What is GPy used for?
GPy is a Python framework for Gaussian processes, models that put a probability distribution over functions rather than a single fitted curve. The project describes itself as the Gaussian processes framework in Python, dates itself to 2012, and publishes under BSD-3-Clause. The README itself contains no API examples, so the tutorial notebooks and the developer documentation at gpy.readthedocs.io are where the modelling details live.
How do I install GPy?
The README recommends updating scipy to 1.3.0 or later first, preferably through the anaconda distribution, and then running pip install gpy. If the prebuilt install fails, it suggests cloning the repository, checking out the devel branch, running python setup.py build_ext --inplace, and then pytest . The build configuration in pyproject.toml adds context the README omits: the build requires Cython and numpy>=2, and scipy must be available inside the isolated build environment because a Cython source file imports scipy.linalg.cython_blas.
Why does the GPy README still mention Travis CI and setup.py?
Because the README appears to predate the tooling the project now builds with. It shows travis-ci.org, AppVeyor, Coveralls and Codecov badges for the devel and deploy branches, and it documents distutils-era commands such as python setup.py develop and python setup.py build_ext --inplace. Meanwhile pyproject.toml declares a PEP 517 build requiring setuptools, wheel, numpy>=2 and Cython. There are no workflow files in the tree for the four badge services, so the badges are best read as a record rather than proof that those services still gate the branches.
What is paramz and why was it split out of GPy?
The README says the core parameterization was pulled out of GPy into a package called paramz, described as the pure gradient based model optimization. Parameter handling is shared by every model in the library, so extracting it lets that layer be versioned and evolved independently of the modelling code. Users upgrading from older GPy installations were told simply to run pip install --upgrade GPy, and development checkouts to rerun python setup.py develop in the installation folder.
Which branch should I target when contributing to GPy?
Target devel, which is the default branch and the branch every README instruction names, including the build-from-source troubleshooting steps. Pull requests should meet the stated guidelines: PEP8 or pylint, 80 column lines, one commit per smallest concern, and code, tests and documentation together. New models and kernels are meant to go into the existing frameworks in model_tests.py and kernel_tests.py under the testing subfolder. Commit messages should follow the gitchangelog format so the change shows up in CHANGELOG.md.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/sheffieldml-gpy)