quickwit-oss
Splitting tantivy and call for official maintainers
The addition of tantivy-py is the most exciting thing I have seen in tantivy in the last month :)
So far, in the wild, ppl have been using tantivy with C#, node, lua, elixir, with different grades of bindings. I think tantivy-search should host some (python, and maybe C and or node) promising bindings, in order to ensure their perennity and so that these project benefit from tantivy-search growing community...
But that does not mean I should be their main maintainer. In fact, I should probably not dissolve my time further.
@poljar we kind of have been throwing you issues here and there, but just to officialize this, are you ok to be official maintainer of your own project? (you already have the write access of course).
Does someone else want to take over the search-benchmark ? Same question for tantivy-cli ?
Sure, maintaining the bindings shouldn't be a big burden anyways. Apart from the possible API changes around them and adding support for differing collectors there's not much stuff going on there.
Of course not counting possible API changes on the rust tantivy side.
Finding the best way to package it for PyPI. Advertise. .... And then routing the occasional bug report to tantivy when relevant. :)
There is already a test package up https://test.pypi.org/project/tantivy/ Finding a way to build the python documentation will be needed, that's true. And the CI setup. So a little bit more than I mentioned but not by much.
@poljar Would there be a way to ship binaries or is it too much of a rabbit hole?
Should be possible. pyo3-pack should make that easier, we still will need to use setuptools to build the source dist.
One pyo3 project that has a working CI setup and publishes binary wheels is fastuuid.
I mostly scared of the libc. Here is a site describing accurately what can and cannot be done. https://www.python.org/dev/peps/pep-0513/#key-causes-of-inter-linux-binary-incompatibility
pyo3-pack takes this into consideration and the fastuuid lib does use a docker image to build the wheels, more info here: https://github.com/PyO3/pyo3-pack#manylinux-and-auditwheel
I can likely take over the search benchmark and tantivy cli, it was my plan to integrate both these tools into toshi both for benchmarking and also cli tools for toshi
@hntd187
cli tools for toshi > That would be great ! We could then sunset tantivy-cli!
I’m not familiar with the inner workings of Tantivy, so I can’t speak to its internal structure. In general, though, when it comes to libraries, the ease of creating bindings largely depends on how the code is structured—whether the files and methods are global and platform-agnostic, or if they rely heavily on platform-specific features, or any other complexities.
If the design is clean and straightforward, creating bindings can often be done relatively quickly. On the other hand, if the implementation is complex or tied closely to platform-specific principles, it might be more time-consuming and less practical to pursue.
If it turns out the former is true, I’d be open to exploring the possibility of contributing some time to develop C# bindings.
