I have a rust library which provides useful functionality for use in other rust programs. Additionally I would like to provide this functionality as a python extension (using pyo3 and setuptools-rust, although expect most practices to be tool agnostic)
- What best practices are there for separating and packaging this? The documentation examples all show a single library. This means that anyone building the rust library and using it in the rust ecosystem needs the python headers and gets the exported python module as well, which isn't great.
- Is there any guidance on testing the exported python extensions within rust rather than only from python? (so I don't need to manually
pip install -e .in order to build the extension before running the tests)
I'm guessing the "right" approach to (1) uses workspaces?
My current setup is:
FizzBuzz
- src
- lib.rs
- tests
- test_fizzbuzz.rs
- test_fizzbuzz.py
- Cargo.toml
- pyproject.toml
Cargo.toml:
[package]
name = "fizzbuzz"
...
[lib]
name = "fizzbuzzo3"
path = "src/lib.rs"
crate-type = ["cdylib", "rlib"]
[dependencies]
pyo3 = "0.20.3"
pyproject.toml
[build-system]
requires = ["setuptools", "setuptools-rust"]
build-backend = "setuptools.build_meta"
[project]
name = "fizzbuzz"
...
[[tool.setuptools-rust.ext-modules]]
target = "fizzbuzzo3"
...
I'd like to split this into two rust libraries:
- one tested by test_fizzbuzz.rs only containing the rust implementation of the functionality
- and a separate one test by both test_fizzbuzzo3.rs and test_fizzbuzz.py covering the python binding
I should be able to edit the code in the rust library and see the change when running all three test suites, then later publish the rust crate and python package to crates.io and pypi.org