mirror of
https://github.com/games-on-whales/inputtino.git
synced 2026-10-15 12:52:02 +00:00
[GH-ISSUE #3] Publish Rust bindings on crates.io. #3
Labels
No labels
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/inputtino#3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hgaiser on GitHub (Apr 28, 2024).
Original GitHub issue: https://github.com/games-on-whales/inputtino/issues/3
Hey! I see you're making good progress on this :). The C API looks nice and clean from what I saw so far.
Do you have any plans on publishing the Rust bindings on crates.io? I have absolutely no idea if, or when I would like to add this to moonshine, but at the very least I would like to add it as TODO for someone to pick up.
A related question: do you have any plans to make a Rust wrapper on top of the bindings? I think they can be pretty straightforward and would help adoption in Rust :).
@ABeltramo commented on GitHub (Apr 28, 2024):
There's already a barebone Rust project under bindings/rust. I was mainly focusing on having a working build environment using
bindgen.I'd like to first wrap all the "unsafe" code and expose a nice Rust API so that it can be easily consumed, and then eventually publish it on crates.io
@hgaiser commented on GitHub (Apr 28, 2024):
Great :) looking forward to it.
Ps. I like to use a bindgen script instead of building the bindings dynamically, like here. Saves another dependency ;)
@ABeltramo commented on GitHub (Apr 28, 2024):
That's interesting, what would be the difference between manually installing it with cargo and having it defined as a
[build-dependencies]like I've done here? I kind of like that it basically does that step automatically for you when building the project..@hgaiser commented on GitHub (Apr 28, 2024):
The main advantage would be that it is one dependency less. However, for nvfbc-sys the header rarely changes so it makes more sense there. Since you're actively developing it, maybe it's better to have it build dynamically in build.rs :)
@hgaiser commented on GitHub (Jun 4, 2025):
Hey, could you update the crate on crates.io? You'll need to publish inputtino-sys as well ^^
Also, not sure if you'll run into issues from "updating" from v2024.x.y to v1.0.0 or w/e version number you want to use 🙄
@polarathene commented on GitHub (Jan 14, 2026):
For reference, bindings were merged via this PR: https://github.com/games-on-whales/inputtino/pull/18
The project README should probably also link back to
crates.iopage?That's also a bit odd, there shouldn't be a mismatch between the
Cargo.tomlrelease and thecrates.ioversion? (the lack of release tags to associate to updates doesn't help either)Using CalVer style (
2024.8.1)instead of SemVer in Rust crates is unconventional (against spec/expectations, especially for libraries) and unwise...Since CalVer is largely meaningless in this context, it'd be better to respect SemVer, but for proper resolution you'd need to version bump to at least 2025 and go from there. Staying on CalVer lacks any ability to communicate breaking changes, it's effectively an incremental value with some context that you could just as easily infer from other metadata associated to the release.