Publish to crates.io #2

Bromeon · 2022-10-03T20:50:15Z

As soon as the library becomes a bit more stable, we can release our first 0.x versions to crates.io.

Crate publishing was in the past blocked by unreleased dependencies, see PoignardAzur/venial#32. Should be good now.

The codegen approach from "output directly in dependent crate" needs to be modified, so that all files are output in the own crate.

The text was updated successfully, but these errors were encountered:

211: Prebuilt Godot artifacts r=Bromeon a=Bromeon Closes #12 Closes #107 From now on, gdext by default fetches pre-generated versions of these files, published in the [`godot4-prebuilt`](https://github.com/godot-rust/godot4-prebuilt) repo: * `extension_api.json` (from Godot binary) * `gdextension_interface.h` (from Godot binary) * `gdextension_interface.rs` (through bindgen -- currently supports 3 platforms) This has several benefits: 1. Significantly fewer dependencies, as bindgen is no longer needed, and thus smaller compile times. 2. Most CI jobs no longer need the Godot binary (clippy, test), speeding up CI _in addition_ to (1). 3. It's possible to change the Godot API behind gdext without manually rebuilding the artifacts. 4. Easy comparison between the Godot APIs of different released versions. ### Using a custom Godot binary It is still possible to generate those files locally like before, through the use of the `custom-godot` feature on the `godot` crate. This is necessary for any platform/configuration different from the 3 main supported ones (because bindgen generates different Rust bindings), as well as any in-development or modified Godot versions. ### Changing the Godot release By default, the latest Godot release is used as input to gdext. Switching between different Godot versions is easily possible, although a bit cumbersome. If you want to use an older version `4.0`, add this to your **workspace** (not sub-crate) `Cargo.toml`: ```toml # We need to trick Cargo into seeing a different URL; rust-lang/cargo#5478 [patch."https://github.com/godot-rust/godot4-prebuilt"] godot4-prebuilt = { git = "https://github.com//godot-rust/godot4-prebuilt", branch = "4.0"} ``` We're looking into ways to simplify this. In a crates.io release (#2), we would need to rethink this anyway, mapping Godot versions to Rust release versions (which is not trivial). Co-authored-by: Jan Haller <[email protected]>

Bromeon · 2024-04-17T08:35:05Z

My current plan for crates.io release with multiple Godot versions:

We have a dedicated crate that stores prebuilt Godot artifacts like extension_api.json or gdextension_interface.h.
- Such a crate would track Godot 4.x-stable releases with its own version scheme.
- Since GDExtension API is released only in minor versions, we would only have a release for 4.3, but not on 4.3.1.
- If there are important bugfixes in the GDExtension API (not implementation) and the above turns out not to be enough, we may also include patch releases like 4.3.1.
The main crate godot by default depends on the latest Godot release.
- Raising the Godot API level requires a semver bump.
To support older Godot versions, you can opt in to a respective GDExtension API level via Cargo features.
- godot = { version = "...", features = ["api-4-1"] }
- These are mutually exclusive.
- One day, Rust may implement this properly, but we have to use what we have today.
- mlua uses a similar approach with lua51, lua52, lua53, lua54 features.
To support custom versions (e.g. locally built ones), we can also use a feature.
- godot = { version = "...", features = ["api-custom"] }
- This cannot be used together with other api-* features.

This also means that if two crates a and b depend on the same version godot 0.5, they will by default get the same Godot API level (let's say 4.3). If a now specifies an api-4-1 feature, this will override the choice of b, too. This either works out of the box, because b only uses features that are already available in 4.1 (or polyfilled). Or, it fails to compile if 4.2 or 4.3 exclusive features are used.

An alternative approach would be to always require explicit API level. This may be more explicit, but for dependents that don't care about the API level, it makes things less flexible: if b specified api-4-3, it would be categorically incompatible with a's api-4-1 -- even though GDExtension may permit this. So I'd probably try the above approach first.

Yet another idea would be to take the minimum of any specified API level. If one crate specifies api-4-1 and another api-4-2, then API level 4.1 is selected. This bears the risk that features only introduced in 4.2 are unavailable, thus failing compilation -- but at least coexisting api-4-1 and api-4-2 would not always fail. However, this minimum logic may be hard/impossible to implement with the Cargo dependency system, as we can't simply depend on one prebuilt version.

Bromeon · 2024-06-24T19:53:07Z

🚀 We are now on crates.io!

See devlog article 🙂

@rpc

The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().

@rpc

The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().

@rpc

The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().

@rpc

The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().

@rpc

The style is similar to GDScript's @rpc annotation, the macro can be used as follows: godot-rust#1 - Separate arguments: ```rust #[rpc(any_peer, reliable)] fn some_rpc(&mut self) { //.. } ``` Providing overlapping arguments generates a compile error. Any omitted arguments are set to their default values. godot-rust#2 - Provide an expression: ```rust const CONFIG: RpcArgs = RpcArgs { mode: RpcMode::Authority, ..RpcArgs::default() }; #[rpc(config = CONFIG_EXPR)] fn some_rpc(&mut self) { //.. } ``` Number godot-rust#2 is useful in case you want to reuse the configuration on multiple functions. Number godot-rust#2 is mutually exclusive with number godot-rust#1. --- The generated macro code works as follows: - Caches the configuration in a `ClassPlugin`. - On `__before_ready()`, searches for the configuration in the plugin, registering them with Node::rpc_config().

Bromeon added quality-of-life No new functionality, but improves ergonomics/internals c: tooling CI, automation, tools labels Oct 3, 2022

Bromeon added a commit that referenced this issue Jan 28, 2023

CI #2

127203d

Bromeon mentioned this issue Feb 3, 2023

Add support for typed arrays #101

Merged

Bromeon mentioned this issue Apr 1, 2023

Prebuilt Godot artifacts #211

Merged

Bromeon mentioned this issue Nov 27, 2023

Jetbrains IDEs don't support static analysis of generated code in OUT_DIR #506

Closed

Bromeon closed this as completed Jun 24, 2024

Houtamelo mentioned this issue Sep 19, 2024

Add #[rpc] attribute to user-defined functions #902

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Publish to crates.io #2

Publish to crates.io #2

Bromeon commented Oct 3, 2022 •

edited

Loading

Bromeon commented Apr 17, 2024 •

edited

Loading

Bromeon commented Jun 24, 2024

Publish to crates.io #2

Publish to crates.io #2

Comments

Bromeon commented Oct 3, 2022 • edited Loading

Bromeon commented Apr 17, 2024 • edited Loading

Bromeon commented Jun 24, 2024

🚀 We are now on crates.io!

Bromeon commented Oct 3, 2022 •

edited

Loading

Bromeon commented Apr 17, 2024 •

edited

Loading