-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support RubyGems / Bundler #358
Conversation
I've tried two approaches to implement the Component Model for Ruby. The first one is the *binary-editing* approach and the second one is *extension-library* approach. The basic idea of binary-editing* is to inject import/export sections into a preview1 compatible .wasm binary and turn it into a Component by `wasm-tool component new` command. The approach was good for binary reusability. The binary before injection can be used as a standalone WASI preview1 binary. Therefore user can use a pre-built .wasm binary and just inject the import/export sections to turn it into a Component. However, considering the future dynamic linking support, the approach introduces a bunch of complexity. In the dynamic linking era, an extension library will be able to provide a WIT interface and a Ruby core interpreter should not import or export anything except for WASI. The binary editing approach needs to edit the Ruby core interpreter binary every time when WIT world changes, so the build process would be different from the one of dynamically linked extension library. I decided to go to the extension library approach for mainainability. The static linking build is just for a compatibility with the existing Wasm runtimes, so I don't want to pay much effort for maintining it. The extention library approach uses almost the same build process for static linking and dynamic linking, so it's easier to maintain and we can focus on the dynamic linking support.
5a84e7d
to
ff26de2
Compare
ff26de2
to
5be8b84
Compare
The latest master broke the build. This commit pins the version to the last known working commit.
2bae78b
to
c6f2adc
Compare
Since there is no guarantee that the host system and the builder container use the same Ruby ABI
c6f2adc
to
ad90910
Compare
to control cache key in rake
c630a67
to
e9f5f6c
Compare
to use Bundler in rbwasm command
e9f5f6c
to
cf92cd9
Compare
Could we also add to the FAQ a few examples for gems that are supported? From the above I now know that rainbow gem is supported. I'd like a few more - does not have to mention EVERY gem, but, say, half a dozen (aka 6) gems that we could experiment with would be nice. Also the example used bundler. Can we use "gem" too? If so, how? All my gems use a .gemspec file; I do not really use bundler myself so I am curious if I can avoid bundler (I am aware it is bundled via gem itself nowadays, but I still don't want to have to maintain any Gemfile from bundler, I am too happy with .gemspec since many years). |
Demo
What's Added
exe/rbwasm
: CLI tool to build.wasm
file packaging gems.rbconfig.rb
bundle install --standalone
rbwasm
generatesbundle/setup.rb
as well asbundle install --standalone
ext/ruby_wasm
: An extension library to use wasi-vfs and wizer from Ruby.What's Changed
js
library is now gemified: Moved underpackages/gems/js
*-js
build profiles, which additionally linkjs
extension, are now generalized as a RubyGems application.packages/npm-packages/ruby-wasm-wasi/Gemfile
specifies gems to packageTODO
rbwasm pack
command as an alias ofwasi-vfs pack
#361rbwasm
uses a custom ext library builder instead of RubyGems' one since RubyGems' builder always expects dynamic linking and mkmf does not supportmake install
for static linking.With dynamic linking, I hope we can use RubyGems' ext builder.
nokogiri
does feature detection using ruby's C header files but they are not ready beforemake install
of CRuby build. This problem will be solved by dynamic linking, which allows building ext library aftermake install
of CRuby build.ext/ruby_wasm
extension as fat-gemsrubies/ruby-3.3-wasm32-unknown-wasi-full.tar.gz
in gem package