Introducing Traveling Ruby | Hacker News Reader

Introducing Traveling Ruby

phusion.github.io

77 pointsrmoriz16 comments

Sorry to seem negative, but what does this give that traditional package managers don't?

The pain of ruby versions / gem versions are often felt by developers who are working with various untested components.

For traditional end users a package manager hides all of this and by typing "pkgmgr install rubyapp" it will pull in stable and well tested versions of ruby plus any dependencies. Applications installed this way should just work without the user going anywhere near rubygems.

So the real value added here is for developers not having to create/manage packages? Surely this is offset by the huge number of issues that working outside of a package manager causes. No shared libraries/dependencies, no universal way to update everything, no ability to manage installations with tools such as puppet/chef, no global mirror network, no assurances of package integrity, ect.

Most folks using macs don't use a package manager.

Not sure what you meant with _most folks_, but I'm under the impression that most people on mac, who use the Terminal on a daily basis, use homebrew as their package manager.

edit: typo

Most people on mac don't use the Terminal.

I don't think the target audience (end users) are people who use the Terminal on a daily basis.

Actually, the target audience of Traveling Ruby is primarily users who use the terminal often. See https://news.ycombinator.com/item?id=8718614, where I explicitly mentioned Chef Solo and Heroku Toolbelt as two example use cases for Traveling Ruby.

You can still use Traveling Ruby as part of a toolkit for making an app that's targeted at non-terminal-using end users. For example, by making a GUI app that shells out to a CLI engine that's written in Ruby, powered by Traveling Ruby.

This is very interesting. How will this affect RubyMotion?

Traveling Ruby author here. This is not for phone apps. It is for Linux and OS X apps.

It is also not for graphical apps. Instead, it's primarily for command line apps. Potential examples of use cases that it's trying to cover:

- Chef Solo

- Heroku Toolbelt

Both of the above are written in Ruby, and both of them are command line apps targeting users who are familiar with the command line, but neither of them are necessarily used by Ruby programmers. Thus, users of the above two tools should not have to install Ruby first.

Great project! Also, why not target the regular chef-client too? Managing a ruby installation with gems may be unnecessary on servers too.

I only spelled out potential use cases. Opscode might also be able to use Traveling Ruby to package chef-client, but I've only had experience with chef-solo so I can't comment on chef-client.

RubyMotion is not a traditional Ruby, it generates binaries that basically look basically like what an Obj-C program would generate. It's also not portable to Linux.

I'm curious if Docker is a build-time or run-time dependency on Linux. I tried to pick apart the Linux build script, but it's pretty complicated.

Built time only. Docker is only used by the Traveling Ruby authors (i.e. Phusion and contributors) for building the binaries. You, as a Ruby developer who just wants to distribute your app, just uses the binaries that we have already built and uploaded somewhere. There is no need for you to run Docker.

On Linux, Docker is used to provide a controlled, isolated build environment. In other words, it serves as a "holy build box" (https://github.com/phusion/traveling-ruby#why-it-is-difficul...). There is no native Docker for OS X (i.e. a Docker which can run OS X binaries) so on OS X we try to get as close to an isolated, controlled build environment as we can by setting various environment variables (https://github.com/phusion/traveling-ruby/blob/master/osx/in...), but it's not perfect and I'm sure someone will have just the right amount of Homebrew libraries to interfere with it.

The build scripts are pretty simple. It needs more documentation, but here's the gist:

- setup-docker-container - builds a Docker container which will function as an isolated build environment. Only need to do this once.

- setup-runtime - builds a runtime which is used inside the Docker container. Builds mock chroots and stuff. Only need to do this once. The only reason why this exists is because of limitations in Docker.

- build - builds Ruby binaries, given a runtime directory. It spawns a Docker container which performs the actual building. Inside the Docker container, it invokes the compiler, copies stuff around, etc.

Just follow the hello world tutorial and you'll see how it works.

Very awesome, I had some headaches with this kind of stuff in college.

That's exactly why I don't like ruby. A ruby app usually does not integrate very well with other ruby apps on the system. Especially when company policy mandates that system ruby versions need to be used.

/rant

It's my experience that ruby applications usually require the $latest ruby version. Getting it to run properly with other ruby (diva) applications is just a pain. This is especially annoying if the applications are managed with a deployment tool like puppet. Applying $PATH quirks to get a nice and consistent layout on these machines is not really the solution. Now, your solution whilst certainly being neat just creates another intermediate layer. I'm not sure if this is the solution. How do people manage the os updates on docker images? How how do people handle application updates? What if I want to define that in a sane manner? With puppet I can define a nice and sane process that handles everything from installation to updates to the removal of an app. I have a clear history and I'm able to see what is going on on the machine. I also have a defined and clear process to update the machines.

I'm just guessing but I don't think that your solution is going to work for gitlab without applying a couple of patches to the source files. Routing SSH through port 22 of the host system is going to be a real pain. It also makes future updates a cheerful occurrence.

Nowadays I mostly do development in C, C++ and C# (OSX/Windows and some embedded stuff). Whenever I hear `ruby` or `gem` I start running :)

I also had similar problems with a Go application recently (can you guess which one?).

Traveling Ruby is not meant to be used by users to package up an existing app. It's meant to be used by app developers to package up their apps. You would never use Traveling Ruby to package up Gitlab; instead, Gitlab HQ might use Traveling Ruby to package up Gitlab.

I'm not sure who your rant is targeted at. Traveling Ruby is meant to solve exactly the problem that you're ranting about. Developers use Traveling Ruby to create a package that is self-contained, and no further dependencies, and doesn't conflict with any of the stuff that is already installed.

Think of a Traveling Ruby-packaged app as a single exe. Not physically (because the package consists of multiple files), but spiritually/conceptually (because as a user, you only run a single file, and the result doesn't conflict with anything else on the system). You can compare it spiritually to Go. Go produces single binaries with no dependencies, that you can just run.

You can still integrate this stuff with Puppet or Chef or whatever; Traveling Ruby doesn't stop you from doing that, not makes it harder for you.

Unless you're still on ruby 1.8 (long in the tooth), I don't see how ruby apps from newer versions of ruby will have any trouble integrating with other apps. I can understand a 2.1 app not working on 1.9 or 2.0 in some cases, but backwards compatibility is not the problem. Forwards compatibility is not really a feature of any mainstream language that I know of.

I'm really saddened that there are IT departments that mandate system ruby, though. There isn't even a system ruby on Windows.

Reply on news.ycombinator.com