Add support for bundle gem --rust command

[ianks]

What was the end-user or developer problem that led to this PR?

Despite the recent support of Rust/Cargo as a supported language for developing Ruby gems (#5175), it's still too hard to scaffold out a Rust gem. It should be as easy to scaffold a Rust extension as it is a C extension.

What is your fix for the problem, implemented in this PR?

This PR adds the ability to scaffold a Rust gem by running: bundle gem --rust. A few key points about this integration are:

1. Works perfectly with rake-compiler via the rb_sys gem
2. Opted to use the magnus crate, as I believe it offers the most correct and easy to use bindings for Ruby, plus it supports interop with rb-sys. With magnus, gem authors can avoid writing unsafe code when authoring a new gem in Rust.
3. Scaffolded gems make use of the rb-allocator, so Rust memory usage is properly reported to the Ruby GC.
4. I prefer using the --rust flag over something like --ext=rust. It's much nicer to read and write.

Looking forward to everyone's feedback!

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[chriskilding]

Happy to beta test this once it's semi-ready, if you need a beta tester.

(Bonus: I can test on both an Intel Mac and an M1 Mac)

[simi]

Damn, I have missed one. I have code prepared for --ext=rust (backwards compatible) which seems better to me. I tried to keep it as close as possible with C extension (using ext folder, ...). Would you mind to check that one (548189d) as well? It creates "ext/<%= config[:name] %>.rs", but I wasn't sure how to keep it as close as possible to common Rust package.

Maybe we can just keep the standard Rust (Cargo) structure, but in ext or ext-rust subfolder. WDYT? That way for bundle gem newgem --ext=rust you'll find this structure (next to common gem one):

ext/src/newgem.rs
ext/Cargo.toml

So actual changing directory to ext, you'll get the original Cargo feeling. Also we need to add generated dummy tests for nice and smooth experience. Those were last 2 blockers for me to open PR, but due to lack of time and ideas I wasn't able to move it forward.

Btw. we can make --rust alias to --ext=rust if needed.

[ianks]

Maybe we can just keep the standard Rust (Cargo) structure, but in ext or ext-rust subfolder. WDYT?

Unfortunately this does not provide many advantages, both ext/Cargo.toml and ext/mygem/Cargo.toml will require a root Cargo.toml to provide good editor support.

Given that, I think using the traditional ext/mygem/Cargo.toml structure is the best option, since it makes integration with rake-compiler a bit simpler, and sticks to conventions.

Also we need to add generated dummy tests for nice and smooth experience.

I added some tests in my initial commit, but the bundler unit tests made this hard so I nuked them. I can add them back.

Btw. we can make --rust alias to --ext=rust if needed.

🔥 Sounds good!

[simi]

@ianks do you plan to continue on this or should I take over? I would like to merge with my branch and test.

[simi]

@ianks friendly pingie. I'll have time this weekend, I can try to finish it if welcomed.

[ianks]

@simi can you take it from here? things got busy for me!!

[ianks]

@simi let me know if you run into any issues!

[ankane]

Hi, excited to see this included in Bundler!

I just tried moving a project to this directory structure and think there may be a potential issue.

From what I can tell, the Cargo builder always places the shared library in lib. However, the rake-compiler configuration places it in lib/#{gem_name} (which is what the require_relative expects).

This may be something worth changing or making configurable with the Cargo builder.

Edit: Here's what I needed to change to get it to work with both rb_sys and Cargo.toml (the remove_ext change doesn't apply here and the gemspec change was only made for testing).

[ianks]

For others that stumble on this, check out the structure I setup for wasmtime-rb, I think it serves as a good standard

[ankane]

Hmm, it doesn't seem to install correctly when using spec.extensions = ["ext/Cargo.toml"] and Ruby 3.2.0-preview2.

On installation, it creates lib/wasmtime-rb.bundle on Mac, but lib/wasmtime.rb has require "wasmtime/ext", so it fails with:

cannot load such file -- wasmtime/ext (LoadError)

Edit: require "wasmtime-rb" should work in this case, but for a gem name like hello, you'll end up with lib/hello.rb and lib/hello.bundle and have to use require "hello.#{RbConfig::CONFIG["DLEXT"]}" to require it.

[ianks]

Edit: require "wasmtime-rb" should work in this case, but for a gem name like hello, you'll end up with lib/hello.rb and lib/hello.bundle and have to use require "hello.#{RbConfig::CONFIG["DLEXT"]}" to require it.

Yeah you end up having to use a different name each. It's even a bit more entailed because for cross compiled gems you have to load based on the Ruby version.

[deivid-rodriguez]

This PR can be closed now, correct?

[simi]

Yes Dne st 21. 12. 2022 18:45 uživatel David Rodríguez ***@***.***> napsal:

…

This PR can be closed now, correct? — Reply to this email directly, view it on GitHub <#5613 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABPLEFGBSZ4DCAQ3SWHRQDWOM62PANCNFSM5YGVIDWQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[deivid-rodriguez]

Thanks for getting this started @ianks!