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
[DOC, DISPATCH] : updated and added backend.py
's docs
#7305
Conversation
…IO object at 0x7f446194c5e0>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! It is very helpful. I have a couple of comments below that you should change/adapt as desired.
It might be good to start with language that is aimed at explaining what this is to a user, and then be explicit about when it shifts to being language for someone who wants to set up a backend.
networkx/utils/backends.py
Outdated
1. To be a valid NetworkX backend, a package must register an entry_point | ||
`networkx.backends` with a key pointing to the handler. (`how? <https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/#using-package-metadata>`_) | ||
|
||
You can include the following entry-point in your package's `pyproject.toml` file:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This example works if a package is using setuptools
, but that may not be the case - e.g. if using poetry or some other build tool, or if a package isn't using a pyproject.toml yet. I think it might be good just to note that this is an example specific to that.
Just for context, in poetry this is done using:
[tool.poetry.plugins."networkx.backends"]
entry_point_name = "your_dispatcher_class"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe change the wording to something like:
The way you so this depends on your distribution tools. If you use
`pyproject.toml` you can add the entry-point as follows::
networkx/utils/backends.py
Outdated
[project.entry-points."networkx.backends"] | ||
entry_point_name = "your_dispatcher_class" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why 'entry_point_name' shouldn't just be the backend name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we call it backend_name
here? That's what we call it in the Dispatcher decorator code. So something like:
backend_name = "your_dispatcher_class"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used entry_point_name
instead of backend_name
because I thought backend names have the nx-
in the start and entry-points do not, but I have added a note that clarifies this. Let me know if that looks good to you. Thanks for the review!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've put a bunch of comments below -- mostly in the top part where we are talking about what backends are and how to implement one. See what you think. Push back if you don't think it makes the wording better. :)
networkx/utils/backends.py
Outdated
Also, you might have seen the `@nx._dispatchable` decorator on many of the NetworkX | ||
functions. It is used on functions that can have a backend implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, you might have seen the `@nx._dispatchable` decorator on many of the NetworkX | |
functions. It is used on functions that can have a backend implementation. | |
We are also working on an automatic backend system which could discover which | |
backend to use for different situations. | |
Also, if you've looked at NetworkX function source code, you might have seen the | |
`@nx._dispatchable` decorator on many functions. That decorator makes functions | |
check whether to dispatch to a backend implementation or run the NetworkX code. |
networkx/utils/backends.py
Outdated
computation work to it. Currently, the following backends are supported by NetworkX: | ||
|
||
- `graphblas <https://github.com/python-graphblas/graphblas-algorithms>`_ | ||
- `cugraph <https://github.com/rapidsai/cugraph/tree/branch-24.04/python/nx-cugraph>`_ | ||
- `parallel <https://github.com/networkx/nx-parallel>`_ | ||
- `loopback` is for testing purposes only and is not a real backend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to claim this is the list of backends? Other people could have backends and we would never know about it. Perhaps we can say that these are some examples of backends.
Also, what do people think about moving the backend documentation out of the "Utillities" section and into its own section? The Utilities page is getting pretty long and it might be nice to have a page just for Backends that we could point people to. |
Co-authored-by: Dan Schult <dschult@colgate.edu>
Co-authored-by: Dan Schult <dschult@colgate.edu>
Co-authored-by: Dan Schult <dschult@colgate.edu>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these docs look good. And we can obviously change/improve/adapt them further as we go.
Thanks Aditi for putting this together!
networkx/utils/backends.py
Outdated
Creating a Custom backend | ||
-------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to make all of the header underlines to be one character longer than the header? As far as I know, they're typically the same length in networkx docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the convention is to use the ---
of the same length as the title (ref).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Schefflera-Arboricola ! I pushed up a few formatting updates while being careful to leave the content itself unchanged by and large.
Co-authored-by: Dan Schult <dschult@colgate.edu> Co-authored-by: Ross Barnowski <rossbar@caltech.edu>
https://output.circle-artifacts.com/output/job/b5389424-c908-4ad8-8fa1-fcd1ff17ec74/artifacts/0/doc/build/html/reference/utils.html#backends