
Introducing Traveling Ruby - rmoriz
http://phusion.github.io/traveling-ruby/
======
p8952
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.

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

~~~
muchcomment
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

~~~
srgpqt
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.

~~~
FooBarWidget
Actually, the target audience of Traveling Ruby _is_ primarily users who use
the terminal often. See
[https://news.ycombinator.com/item?id=8718614](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.

------
msie
This is very interesting. How will this affect RubyMotion?

~~~
FooBarWidget
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.

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

~~~
FooBarWidget
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.

------
CGamesPlay
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.

~~~
FooBarWidget
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...](https://github.com/phusion/traveling-ruby#why-it-is-difficult-to-
supply-a-precompiled-ruby-interpreter-that-works-for-all-end-users)). 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...](https://github.com/phusion/traveling-
ruby/blob/master/osx/internal/reset_environment.sh)), 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.

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

------
__mp
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?).

~~~
FooBarWidget
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.

