Recommended packages for graph theory?

Specific Domains Graphs
,
1

I’ve just started to explore graph theory in Julia. And there’s a bewildering array of packages. Some are unmaintained, such LightGraphs.jl and the old Graphs.jl. To confuse matters, LightGraphs.jl seems to be been forked into a new package which is functionally equivalent, but confusingly called Graphs.jl. Then there’s Networks.jl, which seems to be an attempt to port the Python networkx package into Julia, but which also seems to be unmaintained. And lots of others.

I simply want to be able to create a graph whose nodes are strings (or labelled by strings), and then perform some elementary analysis on it: diameter, eccentricities and so on.

The Networks.jl package has the nice syntax for adding labelled vertices:

addnode!(g, "test")

but I can’t see this syntax replicated in the (new) Graphs.jl package. The documentation claims that a node can be any Julia object, but it doesn’t give examples of how to create such general types of node.

So in short, I’m after a currently maintained package for graph theory which allows me to create named vertices (and then undirected, unweighted edges between them), and then also to operate on the graph.
What’s my best option here? Many thanks!

1 Like
2

One possibility is

3

I’ve never worked with graphs so I wouldn’t know, but it’s that not something that Graphs.jl can do?

4

tl;dr Use JuliaGraphs/Graphs.jl and MetaGraphs.jl, keep an eye on MetaGraphsNext.jl

Some background:

Graphs.jl was the original graph package in Julia. By 2016, however, it had become largely unmaintained. Another graphs package named LightGraphs, focused on a slightly different set of use cases, eventually became the de facto standard graphs package in the Julia ecosystem. In 2021, the primary author of LightGraphs departed and the name was retired at their request. At that point, the code base of LightGraphs was grafted back into a forked copy of the Graphs repository, which now lives in the JuliaGraphs organization, wholesale replacing the content of this archived repository. So Graphs was the original graph library; then LightGraphs became the standard; then LightGraphs was renamed to Graphs and replaced the code of the old Graphs… (from the JuliaAttic)

So now, Graphs.jl is (probably) the main package for graphs, at least with regard to how well it’s integrated with the rest of the Julia ecosystem.

But there’s also the ScheinermanVerse, ie SimpleGraphs.jl, a set of graph-related packages that are developed by Ed Scheinerman largely independently of packages in the JuliaGraphs organization (but they can interact). But don’t confuse “SimpleGraph” the package with “SimpleGraph” the Graphs.jl structure though…

Networks.jl (GitHub - JuliaGraphs/Networks.jl: (DEPRECATED) Additional graph flexibility for LightGraphs) and Networks.jl (GitHub - daviddelaat/Networks.jl: A library for working with Graphs in Julia.) are both obsolete, the latter is 10 years old, which is positively Jurassic… They could be resurrected with some (or a lot) of work.

In Graphs.jl, vertices are numbered, not named. So you can use the MetaGraphs.jl package to set properties for edges and vertices.

g = MetaDiGraph()
add_vertex!(g)
set_prop!(g, 1, :name, "vertex one")
get_prop(g, 1, :name)
# -> "vertex one"

Note there’s also MetaGraphsNext.jl, which aims at developing a faster approach to graph metadata.

Graphs.jl appears to be “currently maintained”, but I’d say that the current developers are short of time to devote to maintenance and improvements at present. (A not unfamiliar problem in the Julia ecosystem.)

2 Likes
5

Many thanks indeed for your long and generous reply. Yes, I’d alluded to the old Graphs,jl, LightGraphs.jl, and the new Graphs.jl in my original post. It’s confusing, though. When I added (using the package management system) “Graphs” to my installation, I assumed it was picking up the newest one.

I got round labels of vertices by simply keeping all labels in a list, so that vlabels[i] returns the label associated with vertex i. Maybe this could be done more elegantly with a dictionary, but I’m always happy to work with lists.

As to current maintenance, I have nothing but the deepest respect for all the developers, so I can hardly blame them if a package goes into quiescence for a while. But that’s of course different from a package simply being unmaintained.

Thank you again for your advice!

1 Like