Best way to distribute an app

[Omar Campos]

Hello everyone,

I am still sort of new to all things Ruby, but I am quickly learning
all about the language's capabilities. I program mostly in Windows.
One thing I've noticed, it's that, for a serious application, you will
most probably need to install one or more gems to get all the
functionality you need. Like, if you connect to ODBC, you need the
Ruby/ODBC binding, or binding to your specific database. Which leads me
to wonder, what is the best way to distribute and deploy a ruby
application, especially if it requires external modules?

You could always distribute the necesary gems along with the ruby
installer, and a batch file to manually run "gem install" on each gem,
but this doesn't seem like an optimal solution (would that be even
legal?). What would be recommended way of doing this?

 

[Roger Pack]

You could always distribute the necesary gems along with the ruby
installer, and a batch file to manually run "gem install" on each gem,
but this doesn't seem like an optimal solution (would that be even
legal?). What would be recommended way of doing this?

You may be interested in a question on the ruby-talk FAQ

http://wiki.github.com/rdp/ruby_talk_faq

"How do I convert a Ruby script to an executable?"
Cheers.
-r

 

[David Masover]

what is the best way to distribute and deploy a ruby
application, especially if it requires external modules?

Two main ways: As a gem, or as a git repository.

As a git repository is helpful if by "deploy" you mean "push to a webserver",
in which case, I suggest you look into Capistrano. As a gem is mostly useful
for other developers, but you get all the advantages of a package manager --
dependencies, seamless upgrades, installing/uninstalling handled for you...

I program mostly in Windows.

Ah... is it a desktop application?

In that case, there are a few options. I like rawr. But there are ways to bake
gems into your app, and once you've done that, it's just a question of finding
an installer that'll put your app folder on their hard drive, and give them a
way to launch it.

But seriously, rawr looks awesome, if your app can run in JRuby:

http://rawr.rubyforge.org/

 

[Omar Campos]

Hi, thanks for the replies. I know this question is probably asked a
lot, but thanks. What did you mean about baking gems into apps? I
think rawr fits my needs, but I will also check out Capistrano.

 

[David Masover]

Hi, thanks for the replies. I know this question is probably asked a
lot, but thanks. What did you mean about baking gems into apps? I
think rawr fits my needs, but I will also check out Capistrano.

If rawr fits your needs, Capistrano almost certainly doesn't, and vice versa.
To over-simplify:

Rawr is for deploying apps to desktops.
Capistrano is for deploying apps to servers.

And by "baking gems into apps", I mean what's often referred to as "freezing
gems" -- basically, just before you ship your app, you install all relevant
gems to a subdirectory inside your app folder. Thus, users don't have to worry
about gems at all, it's just as if all the gem code is part of your app.

This is something that I intensely dislike, personally. It's the antithesis of
all that is good and pure about package managers, but it may fit your needs.

 

[Omar Campos]

This is something that I intensely dislike, personally. It's the
antithesis of
all that is good and pure about package managers, but it may fit your
needs.

Duly noted. I will not bake my gems . I will use rawr instead.

What about ExeRb and RubyScript2Exe? Are those any good? I played
around a few years ago with RubyScript2Exe and didn't have much success,
but perhaps it's gotten better? (Don't worry I already downloaded rawr,
but I like to know all my options).

 

[David Masover]

Duly noted. I will not bake my gems . I will use rawr instead.

Well, rawr has exactly the same problems -- as I understand it, the only
difference is that it combines your apps and your gems into one giant jar.

In other words, pay no attention to my rambling.

The main thing I like about rawr is that if you're going that route anyway,
it's a nice cross-platform solution. It builds a Ruby app that's as portable
as any Java app, but gives you native installers for all of them. It also has
an awesome logo.

What about ExeRb and RubyScript2Exe? Are those any good?

No idea, that might be answered in the FAQ someone else mentioned.

 

[Marnen Laibow-Koser]

Omar Campos:


I have yet to try it, but OCRA is mentioned
often on this list: http://ocra.rubyforge.org/

IIRC, it's Windows-only. FWIW, I'm using JRuby and Monkeybars (which
includes Rawr). This and the practice of baking gems will guarantee
that my app will run anywhere there's a JVM, with no other external
dependencies.

— Shot

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
(e-mail address removed)

 

[Omar Campos]

Hello,

I have tried some of the alternatives suggested, and found the
following:

1. Rawr seems to work only on JRuby.
2. ExeRB had problems packing an external library used by my sample app
(FXRUBY).
3. OCRA made the executable and worked perfectly. It is simple to use,
although the executable is quite large (2 MB to be exact) which is
understandable, considering it includes the whole interpreter and
dependencies.

I feel rawr needs further exploration, so I will continue to try it.

 

[Luis Lavena]

Hello,

  I have tried some of the alternatives suggested, and found the
following:

1. Rawr seems to work only on JRuby.

Yes, it's JRuby only

2. ExeRB had problems packing an external library used by my sample app
(FXRUBY).

I've used exerb-mingw (manually built from GitHub) and worked without
issues packaging binary dependencies:

http://github.com/snaury/exerb-mingw

3. OCRA made the executable and worked perfectly.  It is simple to use,
although the executable is quite large (2 MB to be exact) which is
understandable, considering it includes the whole interpreter and
dependencies.

Exerb will generate similar size executable, but contrary to OCRA, it
can be UPX'ed for smaller size.

 

[James Britt]

Well, rawr has exactly the same problems -- as I understand it, the only
difference is that it combines your apps and your gems into one giant jar.

I may not; it depends on what you set in the config file. But
typically, yes, unpacked gems get bundled up into a common jar file.

In other words, pay no attention to my rambling.

The main thing I like about rawr is that if you're going that route anyway,
it's a nice cross-platform solution. It builds a Ruby app that's as portable
as any Java app, but gives you native installers for all of them. It also has
an awesome logo.




No idea, that might be answered in the FAQ someone else mentioned.

One difference is that rawr will compile your Ruby code into Java
classes in such a way to provide very robust code obfuscation, if you
need that. I believe the other options do nothing to hide the Ruby
code, making it available for people to read/copy.



--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

 

[David Masover]

I may not; it depends on what you set in the config file. But
typically, yes, unpacked gems get bundled up into a common jar file.

And if you didn't do so, those gems would have to be installed somehow.

Essentially what I'd look for in an installer like this would be something
that, first, either starts with a gem, or also builds a gem, to make the whole
process that much easier for people who already know about gems. Then, the
binary package (the exe on Windows) detects or installs Ruby and Rubygems,
then installs gem dependencies using Rubygems (perhaps with ri and rdoc
disabled by default). If it was designed for JRuby, it could do the same with
the JVM.

Of course, this means some of it would have to be compiled down to native code
-- perhaps a JRuby app compiled with gcj, if that works? -- so that you get
zero dependencies for the app to run.

The idea is that, first, as Omar noticed, you get a fairly large executable
when you try to bundle everything. Second, you get a ton of dependencies
included, which you then have to manage yourself -- perhaps releasing a new
version of your app (and a new huge download) which only contains gem updates,
for security reasons. In other words, it pushes the responsibilities of
maintaining dependencies back to the developer -- aside from wasting disk
space, RAM, and bandwidth.

If Ruby didn't already have a package management system (Rubygems), I wouldn't
care so much. I still convince myself not to care as much, since I don't write
desktop Ruby apps, I write web apps, and I can control the server environment
and do it right. But it still bothers me, and it's on my list of things to do
when I have time.

On the other hand, this would be a lot more difficult to build to begin with
than something like Rawr. Aside from having to work with compiled code, and
hopefully compile something very small, you'd have to deal directly with each
system -- for example, on OS X, Ruby and Rubygems are already installed, but
you need gcc if you have binary extensions. On Linux, you probably would want
to install Ruby and Rubygems via the users' package manager, but then, you'd
also want your app to be distributed as a package, so maybe an automagic
binary isn't such a big deal. And Windows would be its own nightmare.

But while I'm tilting at windmills, how about a specific user for Rubygems?
Right now, I have two options: Either install gems to my homedir, or install
them system-wide as root. I've overridden this manually by installing them
system-wide, separately for 1.8 and 1.9, in the home directory of a user for
each one. This way, I can have them be sort-of system-wide (not just in my
home directory), without letting them scribble over /bin and /usr/bin as root
(I can configure that anyway, but the fact that it's not running as root
forces the issue) -- I see only advantages to this approach, and no
disadvantages. You could even create a group for users who can call rubygems,
and allow users to configure 'gem' to sudo itself.

But that's more than enough thread-hijacking on my part for one day

 

[Roger Pack]

Essentially what I'd look for in an installer like this would be
something
that, first, either starts with a gem, or also builds a gem, to make the
whole
process that much easier for people who already know about gems. Then,
the
binary package (the exe on Windows) detects or installs Ruby and
Rubygems,
then installs gem dependencies using Rubygems (perhaps with ri and rdoc
disabled by default). If it was designed for JRuby, it could do the same
with
the JVM.

So what you would be looking for is instead of the equivalent of a "one
click installer" it's a one click installer that just installs a version
of ruby and any gems needed, then does other things?

That is an interesting idea. It's the equivalent of an installer that
does 'net download' of some of its components, I suppose.

It does go a bit against the mantra of {at least in the windows world}
an installer is an installer, but it has potential.

My latest thought with installers would be to build one that is the
equivalent of a "traditional" one click installer, but all in ruby,
using visualuruby [windows compatible only]. So basically it unzips
some .tar.gz file into program files\something, which includes all
binaries you might want.

Of course something like that wouldn't work for linux.

I wonder what would be a useful cross platform tool...

Python has http://docs.python.org/distutils/builtdist.html but it seems
to be just for installing the equivalent of gems, and we already have
gems...

Thoughts?
-r

 

[David Masover]

So what you would be looking for is instead of the equivalent of a "one
click installer" it's a one click installer that just installs a version
of ruby and any gems needed, then does other things?

Well, now that I've seen rip, I'm not convinced gems are necessarily the end-
all of Ruby packaging, but that's the idea. Or, more generally, something that
installs the needed package manager if none is installed already, then
installs a set of dependencies.

That could actually be all that's needed, other than adding icons and such for
the result -- the app itself could then be distributed as a gem.

It's the equivalent of an installer that
does 'net download' of some of its components, I suppose.

The point here is not so much that it's a 'net download', as that it brings
the advantages of a package manager to bear -- that is, chances are, there's a
lot of overlap. Does every rawr app really need to include JRuby, MonkeyBars,
Nokogiri, etc, etc?

It does go a bit against the mantra of {at least in the windows world}
an installer is an installer, but it has potential.

There are 'net downloads' in the Windows world also. I can think of one way to
mitigate this, though: The option of a full installer, but one which is aware
of everything else that's installed. Consider the fact that just about every
Windows game ever shipped includes DirectX, but you don't have one copy of
DirectX installed per game -- it only installs/updates if you don't have a
recent enough version already installed.

Consider that with Rubygems, you can have multiple versions of a gem
installed...

To make it even better, make it possible to generate a full installer from any
installed package. Thus, even if you installed with the net-installer (thus
saving bandwidth), you can create a full installer to share over your LAN
(thus saving more bandwidth).

On the other hand, for this to work, we need a really robust packager. In
particular, we need reverse dependencies -- I think rip has this? -- we need
to not even prompt the user, but we need the ability to know that a given gem
was installed as a support library for a given app, so that uninstallation
works the way you expect.

Of course something like that wouldn't work for linux.

Well, for Linux, it's less needed -- we have native package managers, and
users are generally used to these. What's needed on the Linux side is a more
universal package manager, some sort of meta package manager. I think
GoboLinux has some good ideas with their "aliens" hierarchy -- they natively
support Rubygems, and Gobo packages can depend natively on gems, or on CPAN
modules, etc, without having to repackage every gem as a Gobo package.

I wonder what would be a useful cross platform tool...

I'd say start with Windows and OS X, and even if Ruby is an awesome
implementation language, we should shoot for language-independence. And the
reason I say start with Windows and OS X is that neither has an existing
package manager, so we wouldn't be stepping on anyone's toes by basically
building netinstallers all over the place.

I think Linux can be made even better, but it takes a lot more work.