-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First shot at the interface #9
base: main
Are you sure you want to change the base?
Conversation
👀 |
@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 |
Why add Graphs in the test deps? |
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) |
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 |
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 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 |
Okay that seems fair to me, although I wish we could do it in a cleaner way |
Try to implement JuliaGraphs/Graphs.jl#146