Traveling Ruby: self-contained, portable Ruby binaries | Hacker News Reader

Traveling Ruby: self-contained, portable Ruby binaries

phusion.github.io

79 pointsvinnyglennon21 comments

> This tutorial does not cover Windows. This tutorial will not work on Windows; nor will this tutorial generate packages for Windows. The creation of packages for Windows is covered in tutorial 4.

Tutorial 1 tells you how to build a cross-platform Ruby release, doesn't tell you how to build it for one of the 3 major platforms until tutorial... not 2, not 3, but 4. They even tell you in Tutorial 4 that "there are caveats!" and the document almost begs you not to bother.

OSX and Linux users aren't the ones having trouble running Ruby programs. You're not traveling anywhere if you only support POSIX systems that either come pre-installed with Ruby or are a minor command away from having it. This seems entirely pointless to me.

The best option I've found for windows is using OCRA https://github.com/larsch/ocra

Things take development time. The idea is great. I’ve spent a lot of hours fighting rbenv lol

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!

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

CI failing doesn't exactly inspire confidence.

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.

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

A while back I made Ruby Ship (https://github.com/stephan-nordnes-eriksen/ruby_ship) to achieve just this.

It lets you put a full Ruby MRI install in a portable location. Works on most (all?) platforms.

Could be worth a check

And yes; it works on Windows :)

Does anyone have experiences with enclose.io?

http://enclose.io/

https://github.com/pmq20/ruby-packer

I only used it once to test something and it worked nicely.

These days I do a lot more python and xar/pex files are a really convenient way to distribute tooling, I always wished the Ruby ecosystem would have more of this kind of tooling.

Check out nix-bundle.

JRuby (Ruby on JVM) and Warbler[0] solves this problem quite nicely, even though you end up with JARs instead of true binaries. (There are tools for packaging JARs as binaries, if you really want that.)

[0]https://github.com/jruby/warbler

Unfortunately Traveling Ruby stopped at Ruby 2.2.2, which is now end-of-lifed. Anyone know of plans to update it?

(2015), doesn't seem to have had any code updates since Feb 2016.

So, I came across this when I was looking for Lambda support for Ruby (aws). I came to the same conclusion as this thread (and FooBarWidget is here evidently telling us we're not wrong), that it was unmaintained and won't be maintained again soon, unless someone steps up.

I'm just wondering does anyone use Lambda with Ruby (with this or otherwise?) Is it as kludgy as it looks?

I found a couple of better looking options to do FaaS-style development on Kubernetes with Ruby, namely riff and kubeless, but I don't expect supporting code to come for AWS or from Amazon any time soon. Anyone who uses Ruby disagree?

I used Lambda with mRuby, the embeddable version of the language. The (subset of) Ruby code is compiled into a bytecode that is linked to a C program that is run in Lambda and interprets it. The downside is that you either write all your Ruby code or use the few Ruby gems that work in mRuby. They must also be compiled and linked to the main C program.

https://github.com/mruby/mruby

A getting started from 2012

https://matt.aimonetti.net/posts/2012/04/25/getting-started-...

Thanks for that! I wasn't going to find that on my own. You said 'used' as in past-tense... mind sharing why you moved on and what you moved on to?

(Did you implement serverless but in another language? mRuby was too cumbersome from what it sounds like, did you keep Ruby but ditch serverless? How is your stuff hosted today?)

It was an experiment to get used with mRuby. I didn't build anything serious with serverless technologies because my customers are not on them. Some other experiments with Nodejs on Lambda, that's all. However my feeling is that the extra steps from source to binary obe had to take with mRuby are not worth the effort. If one stays within the 100 ms billing unit of Lambda (is it still like that?) it's much easier to deploy interpreted code than compiled one.

Anyone know if you can contain other services like Postgres or Mysql inside it?

Reply on news.ycombinator.com