> 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.
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.
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.
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.
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.)
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.
[+] [-] HelloWorldInWS|7 years ago|reply
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.
[+] [-] castlegloom|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] alaurie|7 years ago|reply
[+] [-] cookrn|7 years ago|reply
Either way, foobarwidget deserves props for releasing this at the time as it’s gotten some great use!
[+] [-] ksec|7 years ago|reply
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
[+] [-] FooBarWidget|7 years ago|reply
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|7 years ago|reply
[+] [-] Cort3z|7 years ago|reply
It lets you put a full Ruby MRI install in a portable location. Works on most (all?) platforms.
Could be worth a check
[+] [-] Cort3z|7 years ago|reply
[+] [-] rb2k_|7 years ago|reply
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.
[+] [-] CMCDragonkai|7 years ago|reply
[+] [-] saltvedt|7 years ago|reply
[0]https://github.com/jruby/warbler
[+] [-] wrs|7 years ago|reply
[+] [-] kristianp|7 years ago|reply
[+] [-] yebyen|7 years ago|reply
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?
[+] [-] pmontra|7 years ago|reply
https://github.com/mruby/mruby
A getting started from 2012
https://matt.aimonetti.net/posts/2012/04/25/getting-started-...
[+] [-] jaequery|7 years ago|reply
[+] [-] vrdududude|7 years ago|reply
[deleted]
[+] [-] symfoniq|7 years ago|reply