Open Chiichen opened 4 months ago
I'm not sure which member of the organization I should communicate with regarding the work on Rust Binding. I just noticed that you participated in previous discussions about Rust Binding, and I wanted to see what your thoughts are on this issue. @snnn @devigned @edgchen1
@pranavsharma / @sophies927, what do you think?
Do the binding need to live in this repository? They target the stable C-API, after all, and this project already has a behemoth of a testing infrastructure. Having the bindings live in a different repository may make their development easier.
Do the binding need to live in this repository? They target the stable C-API, after all, and this project already has a behemoth of a testing infrastructure. Having the bindings live in a different repository may make their development easier.
Currently, there are two mainstream libraries that provide Rust bindings for onnxruntime, one is [ort](https://github.com/pykeio/ort)
and the other is [onnxruntime-rs](https://github.com/nbigaouette/onnxruntime-rs)
ort
: It provides a high level onnxruntime API. However, it doesn't provide any directly low level bindings to onnxruntime. When you use this library, you can only use the pre-built onnxruntime library, and for some platforms (such as Android), you even have to build onnxruntime yourself. This library will not help you do any build work related to onnxruntime itself (these work is usually done by libraries like onnxruntime-sys in traditional rust binding libraries to provide low-level Rust APIs based on C APIs), and this library currently has no plans to support this feature (onnxruntime build)onnxruntime-rs
: It is no longer maintained and the code has been moved to the current project #12606 Regarding why we don't maintain the Rust Binding in a separate repository, I believe the main reason is that starting a project from scratch makes it difficult to ensure long-term maintenance. This issue has been discussed in Coordinating Effort around a community run organization. From the perspective of continuous maintenance, having the binding maintained by the main repository (microsoft/onnxruntime) is the most beneficial choice for the community's development. Another reason is that the current repository already includes a significant portion of the Rust Binding work (mainly from onnxruntime-rs). It seems like a good choice to further develop based on the existing code.
This library will not help you do any build work related to onnxruntime itself (these work is usually done by libraries like onnxruntime-sys in traditional rust binding libraries to provide low-level Rust APIs based on C APIs)
@Chiichen does https://github.com/pykeio/ort/tree/main/ort-sys satisfy the build / low level access you are describing?
这个库不会帮你做任何与 onnxruntime 本身相关的构建工作(这些工作通常由传统 rust 绑定库中的 onnxruntime-sys 等库来完成,以提供基于 C API 的低级 Rust API)
@Chiichenhttps://github.com/pykeio/ort/tree/main/ort-sys是否满足您描述的构建/低级访问?
No, it doesn't. I hope that when I use onnxruntime-sys, it can directly help me build onnxruntime from source code, and link it into the rust program automatically. You will find that this library(ort-sys) does not contain the source code of onnxruntime at all. Actually, It does not build onnxruntime from source code, but directly links to the built onnxruntime static library by specifying ORT_LIB_LOCATION
. This means that for the user of ort
, he needs to build onnxruntime separately once, although it provides some pre-built binaries, but for some platforms (i.e Android), you still need to build it yourself. I've filed an issue (https://github.com/pykeio/ort/issues/246) asking if they could add similar functionality, but they clearly marked it as not planned
There has been a long discussion about adding Rust bindings to this repository( #11992 #7231), but I've noticed that there has been little progress on the Rust bindings since the initial PR #12606 . Here are some current to-do items that I think we can have some discussion around, and I'd be glad to make some contributions to push the Rust bindings forward.