LightGraphs.jl Transition

Specific Domains Graphs
, , ,
62

On October 8, the following 10 packages in General had a direct dependency on Graphs:

Adjacently
Arena
Caesar
CloudGraphs
CriticalDifferenceDiagrams
DistributedFactorGraphs
IncrementalInference
RoME
RoMEPlotting
Soss

Correction: Had Graphs listed in Deps.toml in the registry, but not necessarily for the latest version.

2 Likes
63

https://juliahub.com/ui/Packages/Graphs/VJ6vx/0.10.3?page=2

1 Like
64

Out of these 10 packages:

  • Soss has already been discussed.
  • CriticalDifferenceDiagrams still depends on Graphs 0.10 and would be good to get upgraded so it can be used together with packages depending on Graphs 1.4.
  • The remaining 8 packages belong to the JuliaRobotics organization. 6 packages have migrated away from Graphs 0.10 at various points in time. Arena and CloudGraphs still depend on Graphs 0.10.
8 Likes
65

Hi I have a much smaller issue than compats, I hope it is fine if I post it here in case someone else has a similar one.

I can’t load a MetaGraph I saved while using LightGraphs.jl in the past using the new Graphs.jl.

Is this expected or am I doing something wrong? In case it is, is there anything I can do about it?

1 Like
66

How did you save it?

67

Hi thanks for replying!

I saved it with the savegraph function. I have fixed my issue by rebuilding it from the start using Graphs.jl, however I think it was a compat issue because the error said that it is impossible to convert from LightGraphs.SimpleGraph to MetaGraph.MetaGraph because I had MetaGraph updated to 0.7.1 I think.

I hope this is helpful to someone somehow

68

I just found out about this, and have noticed that SimpleWeightedGraph isn’t working anymore. Using the example from https://github.com/JuliaGraphs/SimpleWeightedGraphs.jl:

g = SimpleWeightedGraph(3)  # or use `SimpleWeightedDiGraph` for directed graphs
add_edge!(g, 1, 2, 0.5)

add_edge! gives an error:

ERROR: MethodError: no method matching add_edge!(::SimpleWeightedDiGraph{Int64, Float64}, ::Int64, ::Int64, ::Float64)
Closest candidates are:
  add_edge!(::LightGraphs.SimpleGraphs.AbstractSimpleGraph, ::Any, ::Any) at ~/.julia/packages/LightGraphs/IgJif/src/SimpleGraphs/SimpleGraphs.jl:90
  add_edge!(::LightGraphs.SimpleGraphs.AbstractSimpleGraph, ::Any) at ~/.julia/packages/LightGraphs/IgJif/src/SimpleGraphs/SimpleGraphs.jl:86

Has anyone been using weighted graphs sucessfully?

69

Works normally for me, can you output the content of ]status ?
You should do using Graphs, SimpleWeightedGraphs and not importing any package of LightGraphs, that may cause many incompatibilities.

1 Like
70

does this mean packages are keyed on their names, not on UUID?

71

I don’t know how you reach that conclusion or how it’s relevant to this discussion. No package has changed name, nor UUID. LightGraphs has only changed its URL. Graphs has completely changed it’s contents, a hugely breaking change and the version number has been bumped to reflect that.

72

He’s saying you need to bound the versions after name change. If packages were lookedup by UUID, you wouldn’t need to know any of this saga or look up in forums. You’d try to update and it would say you can no longer import this UUID by Graphs you need to change to OldGraph, you cannot no longer import LightGraphs you need to import Graphs.

73

I think you might be misunderstanding. Packages are looked up by UUID. From here

packages are identified by universally unique identifiers (UUIDs), which get assigned when each package is created.

The code was copied from one package (LightGraphs.jl) to a different one (Graph.jl). Now the code of the former lives under the UUID of the latter. You can think of this as a simple major rework of Graphs.jl. Doing this needed Graphs.jl to get a major version update, which it did to v1.4.

Stephan said the users of the old design of Graphs.jl need to bound the dependency of the package to avoid the major update breaking their code. It has nothing to do to how the Packages are identified. No package changed their name, neither UUID’s.

2 Likes
74

Why would people have to do that instead of keeping the original UUID’s valid? What happened to OldGraphs in your view then?

75

It faced a breaking rework in its entirety. The package wasn’t renamed, just the repo was. The UUID didn’t change. it’s kinda like for the first v1 release of Graphs.jl (where it faced the major rework) it was moved to a new repository. That now coincides to be extremely similar to the now-abandoned LightGraphs.jl repository and package. And the general rule holds, if you want to rely on the pre-v1 of Graphs.jl, you need to set the compat bound for the package to <v1.

And without any actual insight, I guess that a pure name change while keeping the same UUID also has some complexity to it because out of a sudden several identifiers of modules/packages are replaced. Technically that’s breaking and would’ve needed a major version increase. That is, the option to simply have a silent update of LightGraphs with its own UUID would’ve been breaking aswell. So it’s the same amount of work, but you cannot run into it accidentally. And a major release to rename a package would’ve been overkill in my opinion. Just recreating it in a new package feels more like a fresh and clean restart. In the situation right now, you’re just stuck to LightGraphs 1.3.5 until you notice that it was moved and renamed.

And just for the record, none of the UUIDs became invalid. It’s just, that the package behind the LightGraphs UUID was abandoned after 1.3.5 from the technical UUID point of view.

2 Likes