Runtime error wih python3.12 rust-cpython is no longer maintained

[DragonGhost7]

Rust python binding in the library are provided by rust-cpython, however since last month, it is no longer maintained.

Which is slightly a problem, because Python 3.12 has deprecades Py_Unicode representation.

So, during a build with Python3.12, nothing bad happens, but at runtime we get:

Traceback (most recent call last):
  File "/usr/bin/etesync-dav", line 10, in <module>
    from etesync_dav.manage import Manager
  File "/usr/lib/python3.12/site-packages/etesync_dav/manage.py", line 22, in <module>
    import etebase as Etebase
  File "/usr/lib/python3.12/site-packages/etebase/__init__.py", line 6, in <module>
    from .etebase_python import CollectionAccessLevel, PrefetchOption, Utils  # noqa
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: /usr/lib/python3.12/site-packages/etebase/etebase_python.so: undefined symbol: _PyUnicode_Ready

An alternative exists, PyO3, and it should be more-or-less a drop in replacement for rust-cpython. However in addition to have it as a dependancy, a build-dependancy also has it as one,

flapigen-rs also depends on rust-cpython, making it an upstream issue also, in a way.

Is it possible to rewrite just etebase-py, and let upstream worry about upstream, or drop it as a requirement completely? That would mean a slight rewrite. (i already started, do not promise results, just as a though experiment)

[tasn]

I'd love help, I don't I'll be able to find the time to port it to PyO3. Flapigen is awesome though, do they not support pyo3? No plan?

[DragonGhost7]

Funnily enough, no. flapigen for generating python class code is reliant upon rust-cpython. Does not supper pyO3 sadly.

Even more funnily enough, https://github.com/Dushistov/flapigen-rs/issues/342 An issue has been raised, by well, you, in 2020 about migrating from rust-cpython because of a rather similar concern.

No progress has been done.

If it feels better, flappigen doesnt work on python3.12 either, for me at least. Maybe cutting edge is not so good of an idea after all eh.

[Xiretza]

flapigen issue for 3.12 incompatibility: https://github.com/Dushistov/flapigen-rs/issues/460

It's been sitting there for 3 weeks. I don't think upstream will fix this any time soon, so I'm wondering whether it's easier to port flapigen to pyo3 or port etebase-py itself to pyo3, throwing out flapigen entirely.