LightGraphs.jl Transition

mbauman · October 18, 2021, 9:04pm

Well, it’s simultaneously very breaking and not breaking much at all, depending upon your perspective. Since the LightGraphs history is preserved inside Graphs.jl, you can see that pretty much all the code changes are for the module names and documentation and CI. Jumping from LightGraphs to Graphs shouldn’t be very difficult at all (but is technically a “breaking” upgrade since it requires some code changes to do so). Jumping from Graphs v0.10 to v1.4 would of course be a complete re-implementation.

gustaphe · October 18, 2021, 9:17pm

I thought the number was chosen to be the next up from Graphs’ last number. But I see, Graphs 1.4.0 is the feature release following LightGraphs 1.3.5, with the new feature of being named Graphs

This is good, I’m just being facetious.

GunnarFarneback · October 18, 2021, 9:24pm

I have already transitioned one of my packages and I can confirm that the transition is way easy. All I needed to do to get it working with Graphs was to change the Project.toml dependency from LightGraphs to Graphs and switch using LightGraphs to using Graphs.

However, from a semantic versioning point of view this is more than technically breaking. Trying to use a graph from LightGraphs with functions from Graphs doesn’t work at all (*) and my package was documented to take a LightGraphs graph as input. I worked around that with a horrible hack but I expect that a lot of packages really will break user code with the transition.

(*) More specifically, this is what happens:

julia> import LightGraphs, Graphs

julia> graph = LightGraphs.path_digraph(5)
{5, 4} directed simple Int64 graph

julia> Graphs.outneighbors(graph, 1)
ERROR: method outneighbors not implemented.
Stacktrace:
 [1] _NI(m::String)
   @ Graphs ~/.julia/packages/Graphs/mjncd/src/interface.jl:16
 [2] outneighbors(x::LightGraphs.SimpleGraphs.SimpleDiGraph{Int64}, v::Int64)
   @ Graphs ~/.julia/packages/Graphs/mjncd/src/interface.jl:320
 [3] top-level scope
   @ REPL[3]:1

There is nothing strange or surprising about this but it is breaking in a real sense.

Cory_Simon · October 19, 2021, 7:08pm

thank you so much for your efforts. my research group heavily depends/ed on LightGraphs.jl.

cscherrer · October 21, 2021, 4:28pm

Will code depending on the old Graphs.jl work with the new one? Soss depends on that rather than LightGraphs. At least at the time it was much easier to use for non-Int nodes, and my graphs are mostly relatively small. But if that’s being deprecated (is it?) I’ll need to find a transition path.

CameronBieganek · October 21, 2021, 4:46pm

I think the old Graphs.jl has been effectively abandoned for a long time. In fact, the old Graphs.jl was archived in the JuliaAttic github group. Actually, it’s still in the Attic, but now called OldGraphs.jl:

https://github.com/JuliaAttic/OldGraphs.jl

cscherrer · October 21, 2021, 4:54pm

Thanks @CameronBieganek. Docs on JuliaHub give me a 404, so two questions…

Does the new Graphs.jl have a topological sort?
Does the SimpleGraphs module have anything to do with the SimpleGraphs package? Oh wait, or maybe that was in the old Graphs. Sorry, this is confusing me.

CameronBieganek · October 21, 2021, 5:14pm

Yup:

https://juliagraphs.org/Graphs.jl/dev/pathing/#Graphs.topological_sort_by_dfs

Nope, the SimpleGraphs module is unrelated to SimpleGraphs.jl.

SimpleGraph and SimpleDiGraph are the two provided implementations of the AbstractGraph API from LightGraphs (now Graphs).

StefanKarpinski · October 22, 2021, 12:24am

Yes, all old versions of Graphs are still there and work the same as before. The two repos have been merged and hah can think of Graphs 1.4 as a very breaking new release of the old Graphs that happens to have the same API as LightGraphs 1.3.5, aside from the package name.

cscherrer · October 22, 2021, 12:31am

Nice! Guess I need to swap out UUID and version numbers, and maybe it’s all good to go

StefanKarpinski · October 22, 2021, 12:28pm

You shouldn’t have to do anything if you’re using an older version of Graphs. You may have to add a compat entry to make sure it doesn’t get upgraded to 1.4 which has the new LightGraphs API.

Steven_Sagaert · October 22, 2021, 12:37pm

I prefer the name Graphs to LightGraphs anyway. Short & sweet

cscherrer · October 22, 2021, 2:24pm

Looks like I was sill confused. I had first thought LightGraphs was just renamed Graphs, so the UUID would be that of LightGraphs.

I had missed the “very breaking” part of this. Is there any documentation for migration?

I think that would be true if the UUIDs hadn’t been swapped around. But Soss is meant for people to build things on top of, and the UUID setup now means no one will be able to use the new Graph library with Soss unless I update everything.

ericphanson · October 22, 2021, 2:47pm

If you look, the UUIDs have not been swapped around:

So if you are using compat, there should be no breakage to continue using the older versions of Graphs.jl (i.e. “OldGraphs”). If you want to update to v1, then everything is different because it is the LightGraphs API.

cscherrer · October 22, 2021, 3:03pm

That’s even more strange. Removing the version bound and calling ]up updated my Graphs dependency to 1.4, still on

Graphs = "86223c79-3864-5bf0-83f7-82e725a168b6"

The only explanation I can think of it that Pkg is ignoring UUIDs. But it must be something else, right? I mean, that’s the whole point of UUIDs.

I don’t see what that has to do with compat. If the UUID hasn’t changed, shouldn’t I be able to use the latest Graphs with the OldGraphs UUID, and users can separately use (new) Graphs? How is compat relevant to any of this?

ericphanson · October 22, 2021, 3:17pm

I’m not sure we’re understanding each other. The pairing p=("Graphs.jl", UUID("86223c79-3864-5bf0-83f7-82e725a168b6")) has not changed. What’s new is that that package (p) got a new v1.4 version with a new API-- that of LightGraphs.jl.

Why does compat matter? Because that determines what version of p you get: the new v1.4 with the new API, or the older version.

CameronBieganek · October 22, 2021, 3:20pm

As far as I can tell, your Project.toml for Soss.jl is fine the way it is:

[compat]
# other stuff
Graphs = "0.10"

You can just leave it like that, make no changes to Soss.jl, and ignore v1.4 of Graphs.

cscherrer · October 22, 2021, 3:27pm

I see two packages:

Graphs → OldGraphs
LightGraphs → Graphs

The original UUIDs were

Graphs: 86223c79
LightGraphs: 093fc24a

The new UUIDs seem to be

OldGraphs: 86223c79
Graphs: 86223c79

Ok, so now I’m back to thinking Pkg is fine, it’s the UUID managing that’s strange.

And this still seems correct to me.

cscherrer · October 22, 2021, 3:28pm

Say a user wants to use Graphs 1.4 with Soss. Would that work?

ericphanson · October 22, 2021, 3:32pm

Yep, I think that’s all true (except I don’t totally know what you mean by UUID managing-- I think the name and UUID have to go together and not change separately from each other, otherwise I think things would break). The packages were basically merged.

no one will be able to use the new Graph library with Soss unless I update everything

That’s true and I see how that is annoying. Someone (possibly you) could register OldGraphs.jl or a fork of it under a new name and you could depend on that I guess?

FWIW I think this is exactly the same situation as if the maintainers of Graphs.jl released a new very-breaking version (without any LightGraphs stuff being involved).