Binding regex from Python

I have a need for using the regex crate from Python (translation: Python <-> C <-> Rust). I've tried 3 different approaches, and they all have their downsides.

My first attempt was using cffi and manually writing simple FFI functions in Rust [1].
This attempt I'm not confident in, as I'm sure there are gotchas that I'm not aware of.

After doing more research, I discovered the existing C binding (rure).
My second attempt was to write a simple wrapper of rure, to make it easy to build a binary wheel for Python [2].
This attempt failed, and I'm not familiar enough with Rust (or C) to figure out why.
I tried several variations of wrapping rure, but they all failed in similar ways (either Python's cffi responding with symbols missing from the library, or null pointers for structs).

My 3rd attempt was to forego the wrapper and instead include the small amount of Python code directly in the regex-capi crate [3].
I don't mind maintaining a fork in my personal GitHub account for this glue code, but that seems flaky.
I also don't want to foist maintaining Python bindings on the regex maintainers (as it seems rure-go was split out to a distinct repo [4])


Thanks for mentioning this! I can see that you are continuing to maintain the rure-python project!

Now that pyO3 is available on stable Rust, I had the thought: would it make sense to use pyO3 to generate these bindings? But I'm thinking that using rure is probably better, because the hand-crafted bindings are probably already well-designed.

What benefit would pyO3 bring given that the bindings for rure have already been written?


Maybe it would make it slightly easier to add new bindings or something, but... yes, I suspect that there would be basically no benefit, and probably several drawbacks. :grinning:

Those are my thoughts as well. And the regex C API experiences very little change. :slight_smile:

The largest problem with rure-python has been building and distributing binary Python wheels. It's not difficult if you maintain your own private PyPI repo (for say distributing your work-specific code), but if you rely solely on the public one it is a pain. It's difficult to build manylinux compatible wheels. If PyO3 has mechanisms to automate that, it could be a win.