gpt4all

gpt4all copied to clipboard

Describe your changes

Added Rust bindings.

Checklist before requesting a review

• [X] I have performed a self-review of my code.
• [X] If it is a core feature, I have added thorough tests.
• [X] I have added thorough documentation for my code.
• [X] I have tagged PR with relevant project labels. I acknowledge that a PR without labels may be dismissed.
• [X] If this PR addresses a bug, I have provided both a screenshot/video of the original bug and the working solution.

Demo

I have added README to include demos showcasing the usage.

Notes

I have tested these Rust bindings only on macOS and Linux (Ubuntu).

Just a heads-up: I'm not sure whether this is going to get any traction. There was another PR quite a while ago (#966) and it didn't go anywhere.

You might want to join the Discord and talk to someone with a say directly.

@Code-Solver Can you recommend anyone to review this on the rust side?

@Code-Solver If you can join the GPT4All Discord and ping me (@cebtenzzre), I'd like to discuss this PR.

My main concern is that of all of the community contributed language bindings we have, only one is actively maintained and confidently known to work - the node.js bindings. Our python binding is the only one we officially support. This binding can certainly live in your fork, but to accept these changes it would be important for us to have some confidence that you are interested in actively maintaining it in the long term, and updating it whenever the llmodel_c API introduces a breaking change.

As mentioned on Discord, CI integration and/or unit tests would significantly improve the chances of this PR being accepted.

I added a CI step in https://github.com/Code-Solver/gpt4all/pull/2. Its a PR against @Code-Solver's own branch (the one of this PR) so as to not make things more confusing than they need to be. 😅

@sunsided Thank you so much for your review. I've made the necessary adjustments.

One thing that's not entirely clear to me at this moment is usage outside of the gpt4all repo due to the build.rs dependency on a relative path. Does it work when referenced through crates.io?

I used the ./scripts/prepare_for_publishing_crate.py script before publishing to crates.io. This script copies the necessary backend files to the relative path ./gpt4all-backend. Therefore, when the crate is installed via crates.io, it searches for the ./gpt4all-backend path. Otherwise, when not using crates, it looks for ./../../gpt4all-backend.

We are deprecating other bindings because of lack of will to maintain and we've gotten burned with not maintained and low quality bindings. IT could be the case that this binding will be the exception to the rule, but we need to find that out outside the official repo. If this binding can live outside the repository, show that it has a dedicated following, and has active maintainers over a decent enough time period - 6 months to a year - then we can reconsider allowing it into the main repo.