-
Notifications
You must be signed in to change notification settings - Fork 165
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
Native rust API documentation? #108
Comments
I'm not sure if there is a use case for retworkx without python. All the payloads for graphs in retworkx are python objects. You could probably leverage some of the code and functions purely from rust, but the you'd need to rely on PyO3 to set for weights/payloads for nodes and edges in the graph. For example of what I mean, you could look at the random gnp functions that are used to generate graphs: https://github.com/Qiskit/retworkx/blob/master/src/lib.rs#L1183-L1241 That is rust code being used to generate the retworkx PyGraph objects which then gets returned to python. You could use retworkx in a manner like this but at the end of the day it would probably need python. So I guess it depends on what you're looking to accomplish with potential rust interface documentation. If you're just looking for a rust graph library most of what's being used inside retworkx today is based on petgraph and that's probably where I'd go for that. But if it's about writing a rust python extension that interacts with retworkx over a native interface than I agree there is a documentation gap. I actually hadn't thought of this before and it's something that shouldn't be hard to add docs and better support for since most of the functions and structs that exist today should be callable directly from rust. The idea I had in mind when I opened #33 was to have a native defined stable interface for other python extensions to leverage retworkx (similar to numpy's C API). This use case probably already works for other rust python extensions (although I haven't tried this from an external project), but for that issue I was thinking of some applications with existing C/C++ (or cython) extensions that would probably want to interface with retworkx natively instead of going through python. |
I was actually asking about a rust graph library. I googled a bunch but didn't come across petgraph so it looks like your SEO is better :). Might be worth calling out in the readme that you're wrapping petgraph. Might help other people like me trying to find that. Glad the bug report helped you ideate documenting how to invoke from other Rust Python extensions 👍 . Please feel free to close out or adjust the bug however you need. |
Having documentation on this is blocked on: PyO3/pyo3#1444 once we have a good pattern for sharing graph objects between crates then we can document how to do it. |
I also think it's a shame that retworkx only works with Python. I guess you are saying it's sort of because of type StablePyGraph<Ty> = StableGraph<PyObject, PyObject, Ty>; Is it not possible to write routines in a generic way? For example in betweenness centrality, I intentionally separated the python from core of the implementation of the algorithm. |
This commit adds a new workspace crate to retworkx, retworkx-lib, which contains a pure rust library built on top of petgraph for retworkx algorithms and additional non-python specific data structures. Prior to this we didn't really have a public rust API for retworkx as the main output from the retworkx crate was a cdynlib for use with python. By creating a new crate this gives us a place to enable rust reuse of the library for functionality that is not specific to python. Any potential functionality in retworkx-lib will need to be solely reusable in rust without pyo3 or python. The primary retworkx crate will still be primarily for the python library. But for places where it makes sense to expose a rust api we can use the retworkx-lib crate to export those for other rust usage. Closes Qiskit#108
* Introduce retworkx-lib crate This commit adds a new workspace crate to retworkx, retworkx-lib, which contains a pure rust library built on top of petgraph for retworkx algorithms and additional non-python specific data structures. Prior to this we didn't really have a public rust API for retworkx as the main output from the retworkx crate was a cdynlib for use with python. By creating a new crate this gives us a place to enable rust reuse of the library for functionality that is not specific to python. Any potential functionality in retworkx-lib will need to be solely reusable in rust without pyo3 or python. The primary retworkx crate will still be primarily for the python library. But for places where it makes sense to expose a rust api we can use the retworkx-lib crate to export those for other rust usage. Closes #108 * Fix setuptools-rust builds The MANIFEST.in was missing the retworkx-lib crate directory which meant when setuptools built the sdist it wasn't including the source for the crate. So when setuptools-rust was called on building the sdist it errors because it can't find the Cargo.toml for retworkx-lib or any of the source. * Migrate max weight matching to retworkx-lib * Add k_shortest_path module to retworkx-lib * Add README * Start adding api documentation * Add rust tests for retworkx-lib to CI * Add retworkx-lib to the contributing guide * Migrate dfs_edges() to retworkx-lib * Remove unused badges section * Improve documentation and rework lib structure slightly * Add retworkx-lib doc builds to ci * Fix lint * minor doc changes * Tighten capacity for dfs_edges allocation Co-authored-by: georgios-ts <[email protected]> * Make min_scored private * Run rustfmt * Make k_shortest_path score value generic * Mention cargo doc --open in CONTRIBUTING.md * Tweak overview wording * Apply suggestions from code review Co-authored-by: georgios-ts <[email protected]> * Bump ahash version * Add result infallible alias type for doc tests * Make weight_callable() generic for return type Co-authored-by: georgios-ts <[email protected]> * Rename retworkx-lib to retworkx-core * Update retworkx-core/Cargo.toml Co-authored-by: Ivan Carvalho <[email protected]> Co-authored-by: georgios-ts <[email protected]> Co-authored-by: georgios-ts <[email protected]> Co-authored-by: Ivan Carvalho <[email protected]>
What is the expected enhancement?
All the docs reference this as a replacement for the python networkx library. Is there a pure Rust interface available free of Python dependencies? If so some documentation about it would be helpful. If not, then this would be semi-related to #33 to add a native Rust interface.
The text was updated successfully, but these errors were encountered: