Publish Rust bindings on crates.io.

[hgaiser]

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]

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]

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]

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]

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]

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]

For reference, bindings were merged via this PR: #18

The project README should probably also link back to crates.io page?

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 🙄

That's also a bit odd, there shouldn't be a mismatch between the Cargo.toml release and the crates.io version? (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.