Consider an interface-only package?

[CameronBieganek]

It seems like it would be convenient to have a package that defines only the AbstractGraph interface without providing any implementations, similar to how Tables.jl and DataAPI.jl work. That way packages that implement new graph types only need to depend on the interface package.

On the other hand, does the new package extensions feature reduce the need for separate interface packages? I haven't played around with package extensions yet, so I don't know the answer to that question.

[CameronBieganek]

@gdalle Any thoughts on this?

[gdalle]

I think it makes development harder to have two unregistered repos, so I would put it on the back burner for now (not that development is really active either ^^). However I kinda like the idea for the medium term when things are more fleshed out

[cpfiffer]

We did a lot of work on an abstract interface package for MCMC over here, and my experience from that was that it is useful, albeit contentious, to have an interface only package. I personally liked the setup but interfaces can be extremely "sticky" and hard to iterate on once they are in place. Ime I would make this an interface-only package and then just let it grow out.

You may already know some of this but I'll stick it in here since I am not nearly as familiar with the graphs ecosystem as you all. Some conclusions from AbstractMCMC:

• Don't make parts of the interface required. It's more work for people who might only want to implement pieces (Best formalism to define the interface #2). Basically, provide a fallback method that tells you to implement some particular method if and when it is invoked.
• This package (GraphsBase.jl) should contain all abstract types anyone would ever want to inherit from, i.e. AbstractGraph, AbstractVertex or AbstractNode, AbstractEdge, etc. Everything here is good and should be moved over, though this error should contain (a) the type that was called and (b) the method that was invoked.
• Start small and hack shit together, interfaces can be more flexible than you think.
• Traits aren't particularly worth it IMO.
• DO provide a way to identify which methods are not implemented and which are -- we didn't really do this in AbstractMCMC and it ended up being a pain for people. An instructional method like interfaceimplementation(x) or something should give you specific instructions on how to implement each method, provide links to docs, a list of omitted interface methods, etc.
• Very very few interface methods should actually need to be extended. For example, most methods have fallbacks that can be built (sometimes inefficiently) from core methods that return some kind of iterable or count. edges, neighbors, getindex, setindex, etc. should be almost all of what anyone should need to implement (I think you already have this for the most part but I just wanted to state it).

Just some opinions, in no particular order and not particularly well formed.