glue-core: linking visualizations across scientific data files

One core, several front ends

Glue is a python project to link visualizations of scientific datasets across many files, and the repository you are looking at holds the glue-core package, which includes much of the core functionality of glue used for the different front-ends.

Those front ends are named in the README. There is glue-qt, the original Qt and desktop application, and glue-jupyter, a Jupyter front-end for glue, plus a number of plugin packages, with the full list of repositories on the glue-viz GitHub organisation.

That structure is the first thing to understand, because it tells you what kind of dependency you are taking on. glue-core is the library, and the two applications are separate projects that consume it. If your interest is the desktop application, you install that, and the core comes with it. If your interest is scripting, you depend on glue-core directly and never touch either front end.

The feature list is short and describes a specific capability. Interactive, linked statistical graphics of multiple files. Support for many file formats, including common image formats such as jpg, tiff and png, ascii tables, astronomical image and table formats such as fits, vot and ipac, and HDF5. Custom data loaders can also be easily added. And it is highly scriptable and extendable.

The word linked is doing the work in that first bullet. Glue is not a plotting library that draws a chart; it is a way of holding several datasets in one session and making the selection in one view drive the selection in the others. That is a different problem from the one a charting library solves, and it is the reason a scientific user would reach for it rather than matplotlib.

The primary language is Python, the project home is glueviz.org, and the authors listed in the pyproject.toml are Thomas Robitaille and Chris Beaumont, with the [email protected] address given in the README as the place to report problems that the README also gives as the place to report problems.

What the dependency list says about the design

The pyproject.toml for glue-core is worth reading, because the dependency list is a map of what the library actually does.

The scientific stack is there in full: numpy from 1.17, scipy from 1.1, pandas from 1.2, astropy from 4.0 and matplotlib from 3.2. The presence of astropy and h5py alongside the hdf5 binding is the reason the README can claim support for astronomical formats, because FITS and VOTable are astropy's domain, not glue's.

The file format support is broader than that list suggests, because there are dedicated readers: h5py from 2.10 for HDF5, xlrd from 1.2 for the legacy Excel binary format, openpyxl from 3.0 for the modern one, and mpl-scatter-density for the 2D density plots that density surveys need. The two Excel readers side by side is a deliberate compatibility choice, since xlrd stopped handling xlsx when it moved to openpyxl.

The visualisation and geometry support is shapely from 2.0, and fast_histogram and echo handle the histogram computation and the progress reporting. The interactivity layer is ipython from 4.0, and dill from 0.2 is the serialisation library, which is how a session or a plugin state can be pickled.

There are optional dependency groups as well. The recommended group adds scikit-image. The astronomy group adds PyAVM, astrodendro and spectral-cube, which are the tools for velocity moment maps, dendrogram based cluster finding and spectral cube data respectively. The all group includes pillow with an explicit exclusion of version 7.1.0, a specific pin that reflects a real compatibility problem rather than a policy. The docs group pulls sphinx with the automodapi, spelling and book theme extensions, and there is a test group with pytest, pytest-cov, pytest-faulthandler, objgraph and a Linux specific h5py pin, and a separate visualtest group with pytest-mpl for image comparison testing.

The package requires Python 3.10 or newer and the classifiers list 3.10 through 3.14, with the Operating System recorded as OS Independent and the topic as Scientific/Engineering Visualization.

One entry point is declared, glue-config, mapped to glue.config_gen:main, which is the configuration generator.

Installing it, and where the documentation lives

The README is explicit about not repeating the installation instructions. For installation documentation, it says, visit glueviz.org, and the pyproject.toml points at http://glueviz.org as the project homepage.

That is a reasonable division for a project with a documentation site, but it does mean there is no install command in the repository README to copy. What you get from the manifest is the shape of the installation: a package named glue-core, built with setuptools as the build backend, with the version held as a dynamic field, and the readme pointed at README.rst.

The repository layout shows how the project is put together for development rather than for end users. There is a glue directory holding the package itself, a doc directory for the documentation sources, a tox.ini for running the test matrix across environments, and a.ruff.toml for the linter configuration. There is a.pre-commit-config.yaml, a codecov.yml, a CircleCI directory alongside a.github directory, a.readthedocs.yml for the documentation build, a CHANGES.md for the changelog, a RELEASE.rst for the release process, a MANIFEST.in for packaging, and a pyproject.toml.

The badges in the README tell you the process around the code. There is a GitHub Actions CI workflow, a codecov coverage badge, a Zenodo DOI badge with the concept DOI 10.5281/zenodo.13866, and separate user and developer mailing lists on Google Groups.

The DOI and the two mailing lists are the details that distinguish a project with an institutional life from a script. The DOI means releases are citable, which matters if you publish a paper that used a figure made with glue, and the split between a user list and a developer list tells you where the conversation is expected to happen.

Custom loaders and the scripting model

The two extension points named in the README are the ones that make glue usable beyond its built-in formats, and they are linked to dedicated documentation pages.

The first is custom data loaders. The README says custom data loaders can also be easily added, and links to the customization page on the data loaders. The mechanism follows from the architecture: glue-core holds a data model and a viewer layer, and the format-specific part is isolated behind a loader interface. A scientific file format that glue does not know is a loader problem, not a fork of the project.

The second is scriptability. The README calls glue highly scriptable and extendable and links to a page on coding with glue. This is the part that distinguishes it from a desktop application that happens to use a library, and it is the reason glue-core is a separate repository from the Qt application. A user who wants to script a figure, load a dataset, apply a selection and export the result can do it against the library, without the application.

The file format list is worth reading in the original order, because it shows how the project thinks about scientific data. Common image formats first: jpg, tiff, png. Then ascii tables, which are the oldest interchange format in astronomy and still common for catalogues. Then the astronomical image and table formats fits, vot and ipac. Then HDF5, the general purpose hierarchical format that modern simulations increasingly produce.

The FAQ linked from that list covers what data formats glue understands, and the existence of that page alongside the loader documentation suggests the built-in set is broad but not exhaustive, which is exactly the situation the loader extension point is designed for.

One caveat worth flagging for anyone writing a loader. The dependency list includes astropy and h5py, which means the library parses a lot of formats itself rather than shelling out to external tools. A custom loader for a format with unusual structure, a compressed variant or a non standard extension may find that the underlying reader is the hard part, not the glue integration.

Where the trade-offs sit, and what to check first

The honest limits come from the same design that gives the project its value.

The first is that glue is a tool for exploring relationships between datasets, not a tool for producing a figure for a paper. Its strengths are interactive brushing, linking and the ability to hold a large number of files in one session. Its weakness is that the linked model adds machinery you do not need if you have one clean table and one plot to make. For that case a plotting library is the right tool and glue is overhead.

The second is the front end question. glue-core is the engine, and the two applications are separate repositories, so choosing glue means choosing between the Qt desktop application and the Jupyter extension, and those two are not interchangeable. The Qt application is the original and the more complete one, the Jupyter front end is the one that fits a notebook workflow, and the README does not claim parity between them.

The third is dependency weight. The core pulls in numpy, scipy, pandas, astropy, matplotlib, h5py, shapely and more, and the full optional set adds scikit-image, PyAVM, astrodendro and spectral-cube. That is a large install, and on a scientific workstation it is usually already present, but in a container it is a substantial image.

The fourth is the licence situation, and it needs a direct look. The README says Glue is licensed under the BSD License and links the LICENSE file, and the pyproject.toml classifiers say License:: OSI Approved:: BSD License, while the project level licence field says it is a custom one that GitHub cannot categorize. The two statements are close but not identical in form, so if the distinction matters to your organisation, read the LICENSE file at the repository root rather than relying on the badge.

What to verify first, in order. Confirm your file formats are covered, either by the built-in list or by a loader you are prepared to write. Decide which front end you will run, because that determines whether you need the Qt application or the Jupyter extension alongside the core. Check the Python version, since 3.10 is the floor and the classifiers run to 3.14. And read the LICENSE file, because for a project that ships a citable DOI and long mailing list histories, the terms are settled and worth reading once.

On maintenance, the repository is not archived and the last push was on 2026-10-22, with releases v1.27.0 on 2026-06-25, v1.26.0 on 2026-06-02 and v1.25.0 on 2026-02-11. Those are minor version bumps roughly every two months, which is the rhythm of a project that is maintained rather than revamped, and for scientific software that is the rate you want.

Editorial conclusion

Adopt glue-core if your work involves comparing selections across several large scientific data files and you want one linked view of them rather than a set of unrelated plots. Do not adopt it as a general charting library for a single clean dataset, because the linking model and the file loaders are the point and the overhead. Verify first that your file formats are supported or that you can write a custom data loader, that the front end you want, the Qt application or the Jupyter extension, is the one you will actually run, and that the licence file in the repository matches the BSD terms the README states.

Frequently asked questions

Official sources

1. glue-viz/glue on GitHub
2. Issues
3. Project website
4. README
5. Releases