[cookrn]

I’ve been researching Traveling Ruby quite a bit recently and, while disappointed in its lack of updates, am also not convinced it’s the correct solution for easily distributable Ruby apps. The main reason is that each required gem with a native extension needs to be compiled by hand with the irregular/nonstandard flags for it to work with the specially compiled Ruby. While this works, it’s an unsustainable development model that creates a somewhat parallel maintenance track for each gem. I wish Ruby had a better story on this front, but I’m not sure what that looks like. Maybe something could be built with the new JIT functionality in 2.6?

Either way, foobarwidget deserves props for releasing this at the time as it’s gotten some great use!

[ksec]

As far as I am aware, only Ruby Packer [1] does it better. And has been since day 1, not sure why it isn't getting any attention from the community.

An upcoming solution would be Truffle Ruby with SubstrateVM. But turns out Sulong; even with the help of LLVM compiling C to Graal is a little harder than I thought ( May be the fault of LLVM bitcode ). So it is taking a little more time than expected.

[1] https://github.com/pmq20/ruby-packer

[thomasfedb]

CI failing doesn't exactly inspire confidence.

[FooBarWidget]

Thanks for the props. Unfortunately I didn't have time anymore to maintain Traveling Ruby. Until Traveling Ruby aligns better with profitable business cases, I won't have time to work on it.

enclode.io/ruby-packer seems very interesting. They use a very different approach. I wouldn't call it "better" because it has both pros and cons compared to Traveling Ruby. This also relates to your doubts about whether Traveling Ruby's approach to native extensions is sustainable or not.

ruby-packer supplies a patched Ruby. It compiles that Ruby (along with native extensions) locally, and packs it into a squashfs archive. Ruby is patched to look inside the squashfs as well on the real filesystem.

Pros: single file, works with all native extensions.

Cons: you need access to all platforms for which you want to distribute (no cross-packaging support), Ruby must be patched and maintaining patches is very labor-intensive.

For Traveling Ruby, I simply made a different set of tradeoffs. I valued cross-packaging support. I wanted to be able to package for Mac, Linux and Windows while only using a Mac (or only using Linux, or only using Windows), instead of setting up build environments for all 3. This is especially important for Windows support: requiring packagers to setup a Windows system with a proper compilation toolchain is a huge pain. Until we have better cross-compilation tooling in general that works on all 3 platforms, using precompiled native extensions is the only way to make things work.

[hasahmed]

Perhaps there could be a system for users to add compiler configs for such gems.