DeepHypergraph (DHG): a PyTorch library where hypergraph structure carries its own Laplacians and message passing
A pytorch library for graph and hypergraph computation.
At a glance
- What is it?
- DHG bundles low-order and high-order structures, spectral and spatial operations, datasets, metrics, models and Optuna-driven tuning into one PyTorch package. The design bet is that operations should be attached to the structure object rather than to a separate layer registry, and that is what separates it from plain PyG-style toolkits.
- Who is it for?
- Adopt DHG if your data is genuinely many-to-many (co-authorship, co-purchase baskets, set-valued features) and you want Laplacian and message-passing operators available the moment a structure object exists, without writing your own incidence-matrix plumbing. Do not adopt it if you need a large catalogue of pretrained checkpoints, distributed multi-GPU training, or a stable API you cannot afford to re-read after each release.
- Can I use it commercially?
- Yes. Apache-2.0 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 43 days 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem DHG targets: sets that are not pairs
Most graph libraries model an edge as a pair of vertices. That assumption breaks when a relation genuinely involves a group: a paper written by four authors, a basket containing seven products, a protein complex with several subunits. The usual workaround is to expand the group into all pairwise edges, which turns one four-way relation into six two-way ones and discards the fact that the four belong together. DHG's stated purpose is to model that case directly. The README describes it as a framework supporting both low-order and high-order message passing, and enumerates the directions it handles: vertex to vertex, vertex in one domain to vertex in another, vertex to hyperedge, hyperedge to vertex, and vertex set to vertex set. The intended audience is researchers and engineers who already work in PyTorch and want the high-order case to be a first-class object rather than a preprocessing trick. The README frames the graph-to-hypergraph conversion as a possible performance lever: building a hypergraph from a graph may expose high-order connections the graph representation hides. That is a hypothesis the library lets you test, not a claim it proves.
Structure-attached operators, and why that is the architectural choice
The distinguishing design decision is stated plainly in the README: Laplacian matrices and message passing functions are attached to the graph or hypergraph structure, so that as soon as a structure is built, those functions are ready to use while constructing a model. This differs from the layer-first convention common in graph libraries, where you instantiate a convolution layer and hand it an edge index tensor. In DHG the structure object is the carrier of both the topology and the operators defined over it. The README lists the operator families as spectral-based operations such as Laplacian-based smoothing, and spatial-based operations such as message passing from domain to domain. The documented structure coverage spans graph, directed graph, bipartite graph and hypergraph, with the framework diagrams on deephypergraph.com showing the structure layer and the function library as separate but linked parts. The practical consequence is that switching from a pairwise graph to a hypergraph is closer to swapping a constructor than rewriting a training loop, because the operator surface is consistent across structure types. The cost is that you learn DHG's structure API rather than reusing whatever tensor conventions you already have.
The dhg.experiments module and its Optuna dependency
DHG ships an Auto-ML component. The README states that the dhg.experiments module implements Auto-ML on top of Optuna and can tune model and training hyper-parameters automatically, and that it also supports searching over configurations for constructing the graph or hypergraph structure itself. Tuning the structure is the less common half of that offer: most Auto-ML wrappers search over learning rate, dropout and width, while treating the input graph as fixed. Here the construction of the structure is itself a search space, which is coherent with the library's premise that representation choice matters as much as model choice. The README's phrasing that this can easily outperform state-of-the-art models is a claim about tuning generally, not a measured result, and no benchmark numbers are provided in the material. Treat the module as a convenience wrapper that saves you writing an Optuna study, and expect to supply your own search space definition and objective.
Installing DHG and what the package actually pulls in
The README gives two install paths. The stable release is installed with pip install dhg, and the README identifies the current stable version as 0.9.7. The development version is installed from the repository with pip install git+https://github.com/iMoonLab/DeepHypergraph.git, which the README describes as the nightly version that may include the latest methods and datasets but is not the stable release. The package is published on PyPI under the name dhg, which is worth noting because the project name and the import name differ. The README's dependency section is referenced in its table of contents but the supplied text does not enumerate the dependency list, so the exact pinned requirements cannot be confirmed from this material; PyTorch and Optuna are the two dependencies the prose names explicitly. The v0.9.5 release notes state that the project migrated to the UV package manager and adopted PEP 621 project metadata, which means pyproject.toml is the authoritative place to look for dependency constraints and supported Python versions rather than a setup.py. The README's own installation examples are written in a python code block even though they are shell commands, which is a documentation inconsistency rather than a functional problem.
Where DHG gets in the way
The release cadence is the first thing to weigh. The material shows v0.9.5 in September 2025, v0.9.4 in January 2024, and v0.9.3 in December 2022, so the gap between minor releases has been measured in years, while the README news entry for 2026-08-02 announces v0.9.7 with more than thirty bug fixes across structure, metrics, models and visualization modules plus new CI/CD with automated testing and PyPI publishing. A release that fixes defects in four separate modules at once is a signal about how much of the surface had been exercised between releases. The second constraint is scope. The README claims many state-of-the-art models are implemented for research use, but it does not promise pretrained weights, a model zoo with checkpoints, or production serving paths. If your requirement is downloading a trained hypergraph encoder and running inference, this is not that. Third, the API is versioned below 1.0 and the project has already changed its packaging toolchain once, so code written against 0.9.5 may need attention after 0.9.7. Finally, the documentation is bilingual with Chinese and English versions linked from the README, and the news entries are duplicated in both languages, which is helpful for reach but means the English pages are one of two parallel surfaces to keep in sync.
How DHG differs from PyTorch Geometric and DGL
PyTorch Geometric and DGL are the obvious comparison points, and the difference is not feature count but the unit of composition. In PyG the central artifact is a message passing layer plus a Data object holding edge_index; hypergraph support, where it exists, arrives as a separate convolution that takes an incidence matrix you construct yourself. DGL organises around a heterogeneous graph object and a message passing DSL over node and edge types. DHG instead makes the structure the owner of the Laplacians and the message passing functions, so the same call pattern covers graph, directed graph, bipartite graph and hypergraph. That is a real difference in approach: PyG asks you to adapt your data into its tensor format and then compose layers; DHG asks you to build a structure object and then call operators on it. The trade-off runs the other way too. PyG and DGL have far broader coverage of sampling for large graphs, heterogeneous schemas and deployment tooling, and their ecosystems assume the pairwise case as the default. If your problem is a plain graph with billions of edges, DHG's high-order machinery is weight you are not using. If your problem is a set-valued relation and you have been faking it with cliques, DHG's model is a better fit than either alternative out of the box.
Licence, maintenance and upgrade cost
DHG is released under Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files carry prominent change notices; it also includes an express patent grant. This is a permissive licence, but it is not the same as MIT: the notice-retention and change-marking obligations apply if you vendor the code or ship a modified copy, and the licence text itself is the authority rather than any summary here. On maintenance, the repository is not archived and the last push recorded is 2026-08-04, so the project is active. The maintenance burden for an adopter is the release cadence in reverse: long quiet periods followed by large fix batches, as with the thirty-plus bug fixes in v0.9.7 spanning structure, metrics, models and visualization. A team pinning dhg in requirements.txt should pin an exact version and read the release notes before moving, because a jump from 0.9.5 to 0.9.7 touches code paths in four modules. The UV and PEP 621 migration in 0.9.5 is the concrete precedent: packaging changes of that kind alter how contributors and downstream forks build the project, even when the public API is untouched.
Editorial conclusion
Adopt DHG if your data is genuinely many-to-many (co-authorship, co-purchase baskets, set-valued features) and you want Laplacian and message-passing operators available the moment a structure object exists, without writing your own incidence-matrix plumbing. Do not adopt it if you need a large catalogue of pretrained checkpoints, distributed multi-GPU training, or a stable API you cannot afford to re-read after each release. Before committing, run pip install dhg in a clean environment, confirm the installed version against the 0.9.7 shown in the README, and check whether the specific model you intend to use appears in the implemented-models list on deephypergraph.readthedocs.io rather than assuming the library covers it.
Community notes