Building, Packing and Distributing Ruby Applications

[Erik Veenstra]

http://www.erikveen.dds.nl/distributingrubyapplications/index.html

This URL points to the place where I've dumped my thoughts
about building, packing and distributing Ruby applications.
Theory and practice. The ultimate goal is to be able to
distribute just one executable which contains both the
application and the Ruby interpreter.

That's achieved by the combination of Tar2RubyScript [1] and
RubyScript2Exe [2].

It's definitely worth reading if you have to distribute your
Ruby applications!

gegroet,
Erik V.

[1] http://www.erikveen.dds.nl/tar2rubyscript/index.html
[2] http://www.erikveen.dds.nl/rubyscript2exe/index.html

----------------------------------------------------------------

Summary:

This is how I build, pack and distribute my Ruby applications.
Theory and practice. The ultimate goal is to be able to
distribute just one executable which contains both the
application and the Ruby interpreter.

The three main steps are:

* Create the application in a directory (and its
subdirectories).

* Convert this directory into an RBA (Ruby Archive) with `a
../tar2rubyscript/index.html Tar2RubyScript`.

* Convert this RBA into an executable with `a
../rubyscript2exe/index.html RubyScript2Exe`.

I can distribute this executable to my customers as a
standalone application. They don't need Ruby.

They don't need Ruby, because it's embedded in the executable,
along with the application files and libraries and gems.
Everything they need to run the application. To `b run` the
application. Not to install the application. This document
describes a way to create an `tt,b application.exe`. Not a `tt
setup.exe` or an `tt install.exe`.

That are a lot of `tt exe`-s, but it works on Linux, too. OS X
support is working, but not yet released.

----------------------------------------------------------------

 

[Erik Veenstra]

What did you use to draw the diagrams?

With Dia [1]: "Dia is designed to be much like the commercial
Windows program 'Visio'. It can be used to draw many different
kinds of diagrams. It currently has special objects to help
draw entity relationship diagrams, UML diagrams, flowcharts,
network diagrams, and simple circuits. It is also possible to
add support for new shapes by writing simple XML files, using a
subset of SVG to draw the shape."

gegroet,
Erik V.

[1] http://www.gnome.org/projects/dia/

 

[vruz]

They don't need Ruby, because it's embedded in the executable,

along with the application files and libraries and gems.
Everything they need to run the application. To `b run` the
application. Not to install the application. This document
describes a way to create an `tt,b application.exe`. Not a `tt
setup.exe` or an `tt install.exe`.

I agree this is pretty nice to have, especially distributing
applications for Windows customers for example.

But... what happens when you have several applications in the same system ?
You will have several copies of Ruby and associated libraries.

Whilst this is handy for giving away an app contained in a single
exe, (I've tested it and it works really great!) this is very
different from distributing a JAR

The analogy here with the Java world would be having a JRE for each
JAR you install in your system.
That's clearly not a model I want to use in a desktop with several
different apps installed.
For instance, I have no way to update the Ruby runtime environment for
all apps at once, I have to 'compile' and redistribute an exe for each
application, which is not nice for installing a Ruby bugfix.

I don't think these approaches are mutually exclusive, I would
definetly like to be able to run an .RBA from Ruby too, without
having to copy the Ruby environment (the JRE analogous) for every
installed RBA.

I think there is a place for both approaches.
Does the current framework contemplate this other possibility ?

cheers,
vruz

 

[Alexey Verkhovsky]

The analogy here with the Java world would be having a JRE for each
JAR you install in your system.
That's clearly not a model I want to use in a desktop with several
different apps installed.

Have you ever tried to distribute a thick desktop Java application to a
non-geek audience?
Packaging a JRE with the app is the only way to do it that would not
lead you to a temporary loss of sanity.

Various other solutions to this problem, most notably Java Web Start,
simply don't work.

Only problem is the size of the download. JRE is something like 15 Mb.
And non-geek audience may not have broadband access. And a similar
program compiled from C++ may weigh only 1 Mb. Oops...

For instance, I have no way to update the Ruby runtime environment for
all apps at once.

Which is Good Thing (TM) in the scenario above - because nobody else
has, either

If your audience is all on the intranet, you just make sure they all
have the same Ruby (which is easy for the right sysadmin with the right
tools), and then there is no need for any packaging other than Gems or RPA.

--
Best regards,

Alexey Verkhovsky

Ruby Forum: http://ruby-forum.org (moderator)
RForum: http://rforum.andreas-s.net (co-author)
Instiki: http://instiki.org (maintainer)

 

[Erik Veenstra]

They don't need Ruby, because it's embedded in the

I agree this is pretty nice to have, especially distributing
applications for Windows customers for example.

But... what happens when you have several applications in the
same system ? You will have several copies of Ruby and
associated libraries.

Whilst this is handy for giving away an app contained in a
single exe, (I've tested it and it works really great!) this
is very different from distributing a JAR

The analogy here with the Java world would be having a JRE
for each JAR you install in your system. That's clearly not a
model I want to use in a desktop with several different apps
installed.

Don't mix up an EXE with a JAR. An RBA is comparable to a JAR.
The EXE goes one step further and includes the interpreter and
the runtime environment. The latter is not possible with Java.
(Don't challenge me...) If the customer has installed Ruby, he
can use the RBA instead of the EXE. Like JAR's on Java. He
needs the EXE only if he doesn't have Ruby installed.

In other words, he doesn't necessarily depend on Ruby when
using a Ruby application, whereas he depends on Java to run a
Java application. He probably doesn't even care if it's Java or
Ruby, as long as he gets his work done with the application.
The programmer is the one who does care about which language to
use. So, I don't want to bother my customers with installing
interpreters and libraries and stuff which he is not interested
in. That's where my projects are all about.

For instance, I have no way to update the Ruby runtime
environment for all apps at once, I have to 'compile' and
redistribute an exe for each application, which is not nice
for installing a Ruby bugfix.

I regenerate all executables with just one command...

I don't think these approaches are mutually exclusive, I
would definetly like to be able to run an .RBA from Ruby too,
without having to copy the Ruby environment (the JRE
analogous) for every installed RBA.

You can. An RBA is just a plain Ruby script, so you can run it
on "the Ruby platform".

I think there is a place for both approaches. Does the
current framework contemplate this other possibility ?

On my own PC, which happens to be the Ruby devel PC as well, I
run all applications from their own directories. Probably like
you do. I generate the RBA and the executable only when I'm
about to ship the application. Some colleagues have installed
Ruby and work with the RBA. Some don't and use the executables.
Whatever they like.

That's one application that appears (unchanged) in three
different forms. No problem.

gegroet,
Erik V.

 

[Martin DeMello]

http://www.erikveen.dds.nl/distributingrubyapplications/index.html

This URL points to the place where I've dumped my thoughts
about building, packing and distributing Ruby applications.
Theory and practice. The ultimate goal is to be able to
distribute just one executable which contains both the
application and the Ruby interpreter.

Thanks, that's a wonderful resource.

martin