Skip to content
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

Merged
merged 20 commits into from Mar 21, 2024

Conversation

@dschult dschult added type: Documentation Dispatching Related to dispatching and backend support labels Feb 19, 2024
Copy link
Member

@dschult dschult left a 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 Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
@Schefflera-Arboricola
Copy link
Contributor Author

Thanks @dschult @eriknw and @rlratzel for the review!

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::
Copy link
Contributor

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"

Copy link
Member

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::

Comment on lines 45 to 46
[project.entry-points."networkx.backends"]
entry_point_name = "your_dispatcher_class"
Copy link
Contributor

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?

Copy link
Member

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".

Copy link
Contributor Author

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!

Copy link
Member

@dschult dschult left a 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 Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
Comment on lines 22 to 23
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Comment on lines 29 to 34
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.
Copy link
Member

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.

networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
networkx/utils/backends.py Outdated Show resolved Hide resolved
@dschult
Copy link
Member

dschult commented Mar 7, 2024

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>
networkx/utils/backends.py Outdated Show resolved Hide resolved
dschult and others added 2 commits March 16, 2024 07:48
Copy link
Member

@dschult dschult left a 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!

Comment on lines 38 to 39
Creating a Custom backend
--------------------------
Copy link
Contributor

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.

Copy link
Contributor Author

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).

Copy link
Contributor

@rossbar rossbar left a 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.

@rossbar rossbar merged commit 9ad7887 into networkx:main Mar 21, 2024
41 checks passed
@jarrodmillman jarrodmillman added this to the 3.3 milestone Mar 21, 2024
cvanelteren pushed a commit to cvanelteren/networkx that referenced this pull request Apr 22, 2024

Co-authored-by: Dan Schult <dschult@colgate.edu>
Co-authored-by: Ross Barnowski <rossbar@caltech.edu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dispatching Related to dispatching and backend support type: Documentation
Development

Successfully merging this pull request may close these issues.

None yet

7 participants