First shot at the interface

[etiennedeg]

Try to implement JuliaGraphs/Graphs.jl#146

[gdalle]

👀

[gdalle]

@etiennedeg ping me when you want me to make a first pass. I can also fix CI if you want, looks like mostly docstring stuff

[gdalle]

Why add Graphs in the test deps?

[etiennedeg]

For generating the docstrings, I feel it would be weird to have using GraphsBase rather than Graphs in the docstring, plus some of the functions used in the docstring will not be part of GraphsBase. Of course, we need to have the 2.0 branch of Graphs updated and importing GraphsBase (and we will add the 2.0 branch as a dependency for the time of development)

[gdalle]

I don't agree with this. GraphsBase will be a standalone package, and should only rely on its own functions for documentation and testing. The downstream testing with graph algorithms should happen in Graphs itself, and not be upstreamed to GraphsBase. If Graphs breaks, we'll fix GraphsBase anyway

[etiennedeg]

I'm not speaking of testing nor the global documentation, only for the docstring, the main users will only import Graphs.jl and will use ? to get the documentation of the main methods, which are nv, neighbors, etc... It would be weird that the provided examples show using GraphsBase rather than Graphs. Also, some docstrings generate use a generator to get a graph (for example they call path_graph), but these generators won't be in GraphsBase.

The potential users of GraphsBase will already be a bit familiar with Graphs. If they want to use GraphsBase, they will have a documentation page for GraphsBase that explain what is contained in this library. They will not be worried that the docstrings call using Graphs.

[gdalle]

Okay that seems fair to me, although I wish we could do it in a cleaner way