Mercurial > public > mercurial-scm > hg-stable
diff rust/hg-pyo3/src/lib.rs @ 52438:c5128c541021
rust-pyo3: facility for submodule registration, using it for dagop
It turns out that PyO3 has the exact same problem that we encountered
long ago with rust-cpython. The only difference is that the value
of `__name__` is not within the `mercurial` package at this point of
registration.
We reimplement the solution (equivalent to the suggestions in PyO3
issue tracker anyway), this time in a generic module to limit the
amount of boilerplate in subsequent applications.
| author | Georges Racinet <georges.racinet@cloudcrane.io> |
|---|---|
| date | Fri, 29 Nov 2024 23:47:37 +0100 |
| parents | b61c259c5457 |
| children | 20c0472b2ab7 |
line wrap: on
line diff
--- a/rust/hg-pyo3/src/lib.rs Fri Nov 29 22:59:16 2024 +0100 +++ b/rust/hg-pyo3/src/lib.rs Fri Nov 29 23:47:37 2024 +0100 @@ -1,6 +1,19 @@ use pyo3::prelude::*; +mod dagops; +mod util; + #[pymodule] -fn pyo3_rustext(_py: Python<'_>, _m: &Bound<'_, PyModule>) -> PyResult<()> { +fn pyo3_rustext(py: Python<'_>, m: &Bound<'_, PyModule>) -> PyResult<()> { + m.add( + "__doc__", + "Mercurial core concepts - Rust implementation exposed via PyO3", + )?; + // the module's __name__ is pyo3_rustext, not mercurial.pyo3_rustext + // (at least at this point). + let name: String = m.getattr("__name__")?.extract()?; + let dotted_name = format!("mercurial.{}", name); + + m.add_submodule(&dagops::init_module(py, &dotted_name)?)?; Ok(()) }