In the meantime, I can give a brief situation update:
General design is being discussed in the issues of the nascent GraphsBase.jl package, check out the list of issues.
The idea is that GraphsBase.jl will contain the basic interface as well as a few basic structures for graphs with or without metadata. Ideally we would like it to replace SimpleWeightedGraphs.jl, MetaGraphs.jl and MetaGraphsNext.jl at the same time.
The associated code will be transferred there from this PR sometime soon (it’s summer break after all also @etienne_dg is kind of busy with his thesis)
In parallel, we’re trying to clean up Graphs.jl and merge longstanding PRs to release a decent 1.9 (and perhaps 1.10) before the breaking 2.0. Some of that work includes a new wave of tests on generic graphs, introduced by @simonschoelly.
I’ll probably update the JuliaGraphs website soon to link to this discussion and mention the ongoing work.
Nice to hear that so much work is going on with that!
It might be a bit hectic to organize a Zoom call during JuliaCon, but I would be interested in chatting over Zoom about this another time. (EDIT: If there are others interested in having a discussion about this at JuliaCon, happy to loop you in on Zoom @gdalle.)
My biggest takeaway was that if code in Graphs.jl was a bit more generic (i.e. either not as hard-coded for “simple”, i.e. contiguous integer, vertex labels, or more explicit about that assumption when it is really needed), then a lot of code for defining a labelled/named vertex graph type like the one we have in NamedGraphs.jl could be removed or simplified. Perhaps even a VertexStyle trait would be warranted to distinguish different indexing/vertex styles, like the IndexStyle trait in Base Julia. That would be useful since right now functions defined for AbstractGraph in Graphs.jl can be overloaded for non-integer vertex types, but for integer vertex types we can’t currently distinguish that functions are designed for contiguous integer vertices (“simple vertices”) or non-contiguous integer vertices (i.e. general labelled/named vertices that happen to be integers), which causes ambiguity issues.
Sorry if this is rehashing things that have already been discussed, I haven’t been following all of the design discussions in the Graphs ecosystem.
I’d like to talk about graphs and metadata in Julia. I have been rolling my own metadata. I have very little time for Julia these days. But will be at JuliaCon. I am on Zulip (also slack).
I noticed most of the graph-related talks take place on 27.07 Thursday morning at room 32-123. I guess that’s where most of the people interested in Graphs.jl will be. If nothing else is organized at least this can serve as an atypical place and time to mingle.
Dear @gdalle and others: I’ve developed a Posets package for working with partially ordered sets (a.k.a. posets). Posets may be considered a type of graph, though the notation and focus is rather different.
My Posets package is strongly based on Graphs and re-uses function names where appropriate. A reasonable working version is now available here. In the same spirit as GraphsOptim, I also have PosetsOptim which segregates functions that rely on mathematical (integer) programming. That’s available here. I plan to register them soon, but wonder if PosetsOptim really should be a separate package.
I’m wondering if this would be appropriate to add to the graphs ecosystem (i.e. as part of the JuliaGraphs community). I don’t see anything poset specific there.
I’m also open to help with some associated software matters as I’m not at all conversant in git, can’t figure out Documenter, not sure if my code is Blue compliant, and so on.
Hi Ed, thanks for this contribution!
It’s very cool that you based this implementation on Graphs.jl. One thing that comes to mind is that we don’t have many dedicated utilities (or even a specific type) for DAGs. This has come up in past issues, but if you found some missing tools during your work feel free to open more!
I don’t think you really need to go through the trouble of separating Posets from PosetsOptim if you don’t want to. The idea on our end was to avoid bringing in JuMP.jl for everyone who downloads Graphs.jl, but since you will have much fewer users it may not be worth the pain.
As for the package development workflow, you can check out this blog I wrote: Sharing your code
Happy to answer questions if you tag me on some specific problems! See you on GitHub maybe?
At the moment Graphs.jl aims to retain compatibility with 1.6. Once 1.10 becomes the new LTS, that could be a solution indeed.
GraphsOptim.jl still hasn’t been registered (cause I wanted to clean it up first and never took the time). I thought it was a bad thing but maybe it’s actually fine if we want to put these algorithms in an extension of the main package.
@gdalle Thank you Guillame! What is the best way to contact you without cluttering up this thread? Is there a way to send one-on-one messages in Github?
I’ll look at your blog and merge PosetsOptim into Posets so it’s all inclusive.
When I have things where I want them, I’ll register. We can discuss separately if it makes sense for this to be part of Julia Graphs.
Luckily there are no DMs on GitHub, but feel free to ping me on specific issues, or message me on Slack / Discourse I haven’t given the graphs ecosystem much attention this year, cause I’ve been very focused on autodiff, but once I make PI I hope to pursue some grants to revitalize it
also @etienne_dg is kind of busy with his thesis)
I haven’t given the graphs ecosystem much attention this year, cause I’ve been very focused on autodiff, but once I make PI I hope to pursue some grants to revitalize it
-react this, but that’s not enough.
.