Ruby App Distribution

ruby-talk
1

I don't see how RubyScript2Exe would work when it's a virtual machine. Would it package the entire virtual machine inside the exe?

With Tar2RubyScript it requires you to change your script to work with that tool with the oldlocation/newlocation thing. I don't really like the idea of that.

Will the new version of ruby have something similar to jar built into its virtual machine? I looked around the net but couldn't find anything like that.

Joe

···

----- Original Message ----
From: Eric I. <rubytraining@gmail.com>
To: ruby-talk ML <ruby-talk@ruby-lang.org>
Sent: Tuesday, December 4, 2007 10:20:08 AM
Subject: Re: Ruby App Distribution

On Dec 4, 9:25 am, Joe L <superist_...@yahoo.com> wrote:

I was wondering what are the options for distributing a ruby

application. Java has the jar and C++ you can compile to an exe. What options
does Ruby provide? I'm not looking to distribute anything before the
next release. I don't know if something is being added with Yarv to
aide in distribution. Any info would be great.

Take a look at: http://www.erikveen.dds.nl/ruby.html .

You'll find some options there. Tar2RubyScript packages all the files
that comprise a Ruby program into a single file that can be run on a
machine that already has Ruby installed. RubyScript2Exe goes a step
further, and incorporates the Ruby interpreter and all required
libraries into the single file as well, so the target machine doesn't
even have to have Ruby installed.

Eric

====

Interested in hands-on, on-site Ruby training? See
http://LearnRuby.com
for information about a well-reviewed class.

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

2

I don't know all the internals, but essentially, yes. It collects
everything needed to run your script into a self-extracting executable
format.
It has worked great for me in the past, I was able to make a
standalone app which included an FXRuby UI and web support. It was a
pretty large executable, but ran perfectly on an otherwise ruby-free
laptop.

-Adam

···

On 12/4/07, Joe L <superist_joe@yahoo.com> wrote:

I don't see how RubyScript2Exe would work when it's a virtual machine. Would it package the entire virtual machine inside the exe?

3

I should have mentioned this in the last email. I'd like to find something platform independent too. I use Linux personally, but I'd like it to work on Windows, Mac OS X, and of course Linux.

I don't see how RubyScript2Exe would work when it's a virtual machine. Would it package the entire virtual machine inside the exe?

I don't know all the internals, but essentially, yes. It collects
everything needed to run your script into a self-extracting executable
format.
It has worked great for me in the past, I was able to make a
standalone app which included an FXRuby UI and web support. It was a
pretty large executable, but ran perfectly on an otherwise ruby-free
laptop.

-Adam

···

Adam Shelly <adam.shelly@gmail.com> wrote: On 12/4/07, Joe L wrote:

---------------------------------
Never miss a thing. Make Yahoo your homepage.

4

It sounds like a job for Rubygems to me. Your users would need to have
Ruby and Rubygems already installed, but then it would be pretty easy
to install your gem.

···

On Dec 4, 2007 10:35 PM, Joe L <superist_joe@yahoo.com> wrote:

I should have mentioned this in the last email. I'd like to find something platform independent too. I use Linux personally, but I'd like it to work on Windows, Mac OS X, and of course Linux.

--
Bira

http://sinfoniaferida.blogspot.com

5

Joe L wrote:

I should have mentioned this in the last email. I'd like
to find something platform independent too. I use Linux
personally, but I'd like it to work on Windows, Mac OS X,

> and of course Linux.

If you want one single distribution that works on all platforms without having Ruby installed, you have to go with the jar approach (which of course requires Java to be installed).

Here's a screen cast on the subject, released today:
http://koontzfamily.org/david/videos/Rawr_Screencast_0.1.1.mov

Best regards,

Jari Williamsson

6

I guess there really aren't many options right now. A cool solution would be an executable format like jar that worked on all platforms that was ruby specific.

I feel like using a jar is a Java solution, while it might work... it's not Ruby. Someone else suggested using a Gem, but I don't want to require that of people.

Thanks I guess I'll keep an eye out,
Joe

I should have mentioned this in the last email. I'd like
to find something platform independent too. I use Linux
personally, but I'd like it to work on Windows, Mac OS X,

> and of course Linux.

If you want one single distribution that works on all platforms without
having Ruby installed, you have to go with the jar approach (which of
course requires Java to be installed).

Here's a screen cast on the subject, released today:
http://koontzfamily.org/david/videos/Rawr_Screencast_0.1.1.mov

Best regards,

Jari Williamsson

···

Jari Williamsson <jari.williamsson@mailbox.swipnet.se> wrote: Joe L wrote:

---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.

7

If you want it to be available to those who don't already have RubyGems installed or even the Ruby interpreter, then you'll have no choice but to use the JRuby jar approach, or to package the thing for each platform.
With OS X (10.5) you don't have much work to do, depending on what you need, the windows version might be reasonably easy too.
Linux? varies

···

On Dec 5, 2007, at 6:55 PM, Joe L wrote:

I guess there really aren't many options right now. A cool solution would be an executable format like jar that worked on all platforms that was ruby specific.

I feel like using a jar is a Java solution, while it might work... it's not Ruby. Someone else suggested using a Gem, but I don't want to require that of people.

8

gems ships with ruby now. might as well join the fun.

a @ http://codeforpeople.com/

···

On Dec 5, 2007, at 5:55 PM, Joe L wrote:

I feel like using a jar is a Java solution, while it might work... it's not Ruby. Someone else suggested using a Gem, but I don't want to require that of people.

--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

9

Joe L wrote:

I guess there really aren't many options right now. A cool solution would be an executable format like jar that worked on all platforms that was ruby specific.

I feel like using a jar is a Java solution, while it might work... it's not Ruby. Someone else suggested using a Gem, but I don't want to require that of people.

JRuby is Ruby. It's just implemented in a different language and runs on a different VM. Don't think about JRuby in terms of Java. You'll miss out if an anti-Java bias keeps you from trying something that might meet your needs.

- Charlie

10

It is ruby running on top of JVM. And the JVM is pretty good, I have
seen and heard a lot of talk about how superior it is and what cool
stuff it can do. And JRuby may be very good solution for some
problems.

<rant>
However, the one-click-jar is far from portable. It uses Sun
proprietary solution which runs "everywhere" (read: on the platforms
for which they bothered to make a binary). It runs on Windows, at
least the recent NT based. On OS X but it's usually a bit behind when
new version is out, especially for people that do not have the newest
OS X version as well. On Linux it runs on x86 and x86_64. It also runs
on Solaris, and probably HP-UX. There is some ancient and incomplete
port to ppc-linux by IBM, probably as a result of support for their
something360.

If you did not require Swing there are alternative VMs that are free
(and free to compile on anything) but then you would be back to
distributing binary extensions because you would need something like
AWT which is not part of the Java standard library. Also these free
alternative VMs do not have complete standard library. As far as I
understand the issue the Java documentation license does not allow
implementing a library complying with the documentation which is the
primary reason why efforts at implementing complete alternative VMs
did not get very far.

Then there is that "write once run everywhere" thing with which Sun
tries to push Java. If I have never heard that I would probably not
get so much irritated whenever I hear about Java portability.

Java software is *NO MORE* portable than C software. Given the
proprietary nature of the VM it is actually *LESS* portable. It has
all the common portability issues plus it won't run on platforms for
which there is no JVM, ever.

At least the Java software you meet in practice is swamped with
compatibility problems. Most Java software requires specific minor
version of the JVM, and with this one click approach you can hardly
install several versions of the JVM. Yes, the JDK tools have the
option to compile for older runtimes. I have yet to see this working.
When java 1.5 came out, and our CMS software developer upgraded,
everybody had to upgrade their runtime. He said he is compiling with
the compatibility switch but it just did not work. Maybe it's just the
Java crowd being mostly incompetent. I don't know.

What's worse, I have seen a banking application that requires a
specific patchlevel version (yes, specific -pn suffix). This same
application also works only in IE, how portable. Even for applications
that try, I have seen subtle input event handling differences between
Windows and Linux, enough to break stuff. And an application that
would not have sound on Linux - not sure if it simply did not work or
it caused so much trouble they decided to turn it off.

With these version and platform constraints you may need a quite large
vmware stack if you want to run a number of Java applications :->
</rant>

hmm, anyway, thanks for bringing ruby even to such a hostile
environment for the benefit of those stuck in there :wink:

Michal

···

On 06/12/2007, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

Joe L wrote:
> I guess there really aren't many options right now. A cool solution would be an executable format like jar that worked on all platforms that was ruby specific.
>
> I feel like using a jar is a Java solution, while it might work... it's not Ruby. Someone else suggested using a Gem, but I don't want to require that of people.

JRuby is Ruby. It's just implemented in a different language and runs on
a different VM. Don't think about JRuby in terms of Java. You'll miss
out if an anti-Java bias keeps you from trying something that might meet
your needs.

11

Michal Suchanek wrote:

However, the one-click-jar is far from portable. It uses Sun
proprietary solution which runs "everywhere" (read: on the platforms
for which they bothered to make a binary). It runs on Windows, at
least the recent NT based. On OS X but it's usually a bit behind when
new version is out, especially for people that do not have the newest
OS X version as well. On Linux it runs on x86 and x86_64. It also runs
on Solaris, and probably HP-UX. There is some ancient and incomplete
port to ppc-linux by IBM, probably as a result of support for their
something360.

OS X is one version behind, and will probably have a full Java 6 release soon. Java 6 versions exist for Linux 32/64, Solaris, and Windows. And there are at least two alternative Java 5 VMs for Linux, Solaris, and Windows...often many more. There's dozens of Java implementations, and Java 7 source is GPL and rapidly being ported to platforms that don't have up-to-date JVMs (the BSDs, OS X, and more).

If you did not require Swing there are alternative VMs that are free
(and free to compile on anything) but then you would be back to
distributing binary extensions because you would need something like
AWT which is not part of the Java standard library. Also these free
alternative VMs do not have complete standard library. As far as I
understand the issue the Java documentation license does not allow
implementing a library complying with the documentation which is the
primary reason why efforts at implementing complete alternative VMs
did not get very far.

AWT is part of the standard library. And Sun's JVM has been free for years, and now Free in Java 7. You are wrong about any documentation licenses...I'm not sure what you even mean by that. And as I mentioned before, there's dozens of JVM implementations. I'm not sure what more you're looking for here.

Then there is that "write once run everywhere" thing with which Sun
tries to push Java. If I have never heard that I would probably not
get so much irritated whenever I hear about Java portability.

Java software is *NO MORE* portable than C software. Given the
proprietary nature of the VM it is actually *LESS* portable. It has
all the common portability issues plus it won't run on platforms for
which there is no JVM, ever.

C code would not run on platforms where there's no C compiler...but even worse, a given app won't run unless all libraries it uses have versions for that platform as well. There's certainly a "debug everywhere" component to Java apps, but once you compile them they're basically runnable on any Java implementation. C apps, not so much.

But you're still thinking of JRuby in terms of Java here. JRuby is not Java. JRuby is Ruby on the JVM. The JVM exists in dozens of forms, free, proprietary, embedded, and on big iron. With the exception of some of the smaller embedded profiles and some of the incomplete free impls, JRuby allows Ruby to run on any of them...faster than Ruby 1.8.6, and with all the "good bits" of the Java platform available. Don't think of JRuby in terms of Java.

At least the Java software you meet in practice is swamped with
compatibility problems. Most Java software requires specific minor
version of the JVM, and with this one click approach you can hardly
install several versions of the JVM. Yes, the JDK tools have the
option to compile for older runtimes. I have yet to see this working.
When java 1.5 came out, and our CMS software developer upgraded,
everybody had to upgrade their runtime. He said he is compiling with
the compatibility switch but it just did not work. Maybe it's just the
Java crowd being mostly incompetent. I don't know.

I think you're just misinformed, or getting your information from bad sources. It's not anywhere near this difficult...no more difficult than apps that target a specific C library version. Except in this case, you know that one version numbers guarantees you a specific version of every core API you're going to use, from database access to GUIs.

What's worse, I have seen a banking application that requires a
specific patchlevel version (yes, specific -pn suffix). This same
application also works only in IE, how portable. Even for applications
that try, I have seen subtle input event handling differences between
Windows and Linux, enough to break stuff. And an application that
would not have sound on Linux - not sure if it simply did not work or
it caused so much trouble they decided to turn it off.

The patchlevel thing sounds like they probably hit a bug in that impl of the JVM and needed an updated version. That happens to any software.

The IE thing is a web/UI design issue completely unrelated to Java.

Sound on Linux has been a traditionally hard thing to get working for any application, so Java's certainly not alone here either. And the Linux situation has improved for all apps. You're going on really old information.

With these version and platform constraints you may need a quite large
vmware stack if you want to run a number of Java applications :->

Ask anyone who's actually run a lot of Java applications recently, and you'll get a completely different story. You're either getting bad information or only looking for bad information.

And again, please don't think of JRuby in terms of Java.

hmm, anyway, thanks for bringing ruby even to such a hostile
environment for the benefit of those stuck in there :wink:

It's not just for those stuck on Java, it's for those who want a fast Ruby 1.8 implementation plus a whole lot of other bells and whistles.

- Charlie

12

Michal Suchanek wrote:
> However, the one-click-jar is far from portable. It uses Sun
> proprietary solution which runs "everywhere" (read: on the platforms
> for which they bothered to make a binary). It runs on Windows, at
> least the recent NT based. On OS X but it's usually a bit behind when
> new version is out, especially for people that do not have the newest
> OS X version as well. On Linux it runs on x86 and x86_64. It also runs
> on Solaris, and probably HP-UX. There is some ancient and incomplete
> port to ppc-linux by IBM, probably as a result of support for their
> something360.

OS X is one version behind, and will probably have a full Java 6 release
soon. Java 6 versions exist for Linux 32/64, Solaris, and Windows. And
there are at least two alternative Java 5 VMs for Linux, Solaris, and
Windows...often many more. There's dozens of Java implementations, and
Java 7 source is GPL and rapidly being ported to platforms that don't
have up-to-date JVMs (the BSDs, OS X, and more).

> If you did not require Swing there are alternative VMs that are free
> (and free to compile on anything) but then you would be back to
> distributing binary extensions because you would need something like
> AWT which is not part of the Java standard library. Also these free
> alternative VMs do not have complete standard library. As far as I
> understand the issue the Java documentation license does not allow
> implementing a library complying with the documentation which is the
> primary reason why efforts at implementing complete alternative VMs
> did not get very far.

AWT is part of the standard library. And Sun's JVM has been free for

Free if you happen to have the right platform ..

years, and now Free in Java 7. You are wrong about any documentation
licenses...I'm not sure what you even mean by that. And as I mentioned

The Java 5 documentation used to have very onerous license. Have you
ever read it? Maybe the newer ones are better. I heard that Java 7
will be GPL but we are not there yet.

before, there's dozens of JVM implementations. I'm not sure what more
you're looking for here.

Where is a complete Java 5 implementation other than Sun JVM? With the
GUI stuff and all? Everywhere I always see "Sun JRE required". Sure
the situation would be different for server stuff or other
applications where the fancy GUI is not required.

> Then there is that "write once run everywhere" thing with which Sun
> tries to push Java. If I have never heard that I would probably not
> get so much irritated whenever I hear about Java portability.
>
> Java software is *NO MORE* portable than C software. Given the
> proprietary nature of the VM it is actually *LESS* portable. It has
> all the common portability issues plus it won't run on platforms for
> which there is no JVM, ever.

C code would not run on platforms where there's no C compiler...but even
worse, a given app won't run unless all libraries it uses have versions
for that platform as well. There's certainly a "debug everywhere"
component to Java apps, but once you compile them they're basically
runnable on any Java implementation. C apps, not so much.

But you're still thinking of JRuby in terms of Java here. JRuby is not
Java. JRuby is Ruby on the JVM. The JVM exists in dozens of forms, free,
proprietary, embedded, and on big iron. With the exception of some of
the smaller embedded profiles and some of the incomplete free impls,
JRuby allows Ruby to run on any of them...faster than Ruby 1.8.6, and
with all the "good bits" of the Java platform available. Don't think of
JRuby in terms of Java.

When we are talking about Swing frameworks it is something Java, and
probably even Sun JVM specific. How can you abstract Java out then?

> At least the Java software you meet in practice is swamped with
> compatibility problems. Most Java software requires specific minor
> version of the JVM, and with this one click approach you can hardly
> install several versions of the JVM. Yes, the JDK tools have the
> option to compile for older runtimes. I have yet to see this working.
> When java 1.5 came out, and our CMS software developer upgraded,
> everybody had to upgrade their runtime. He said he is compiling with
> the compatibility switch but it just did not work. Maybe it's just the
> Java crowd being mostly incompetent. I don't know.

I think you're just misinformed, or getting your information from bad
sources. It's not anywhere near this difficult...no more difficult than
apps that target a specific C library version. Except in this case, you
know that one version numbers guarantees you a specific version of every
core API you're going to use, from database access to GUIs.

Specifically with libc some common systems allow to install several
libc version, and the right is picked for running the application.
However, Java application for different version of JVM just breaks.

> What's worse, I have seen a banking application that requires a
> specific patchlevel version (yes, specific -pn suffix). This same
> application also works only in IE, how portable. Even for applications
> that try, I have seen subtle input event handling differences between
> Windows and Linux, enough to break stuff. And an application that
> would not have sound on Linux - not sure if it simply did not work or
> it caused so much trouble they decided to turn it off.

The patchlevel thing sounds like they probably hit a bug in that impl of
the JVM and needed an updated version. That happens to any software.

The IE thing is a web/UI design issue completely unrelated to Java.

Sound on Linux has been a traditionally hard thing to get working for
any application, so Java's certainly not alone here either. And the
Linux situation has improved for all apps. You're going on really old
information.

This is the impression that gradually built as I got into contact with
Java applications over a few years. Although some experience is quite
old I still do not see any improvement.

> With these version and platform constraints you may need a quite large
> vmware stack if you want to run a number of Java applications :->

Ask anyone who's actually run a lot of Java applications recently, and
you'll get a completely different story. You're either getting bad
information or only looking for bad information.

Yes, if you do not need too many, and are careful about upgrading the
JVM (ie never upgrade it until you get an application that does not
work anymore) you should be usually fine. But if you dust off an older
application for managing some piece of hardware that's just getting
out of service you may need a dedicated box for it :slight_smile:

And again, please don't think of JRuby in terms of Java.

> hmm, anyway, thanks for bringing ruby even to such a hostile
> environment for the benefit of those stuck in there :wink:

It's not just for those stuck on Java, it's for those who want a fast
Ruby 1.8 implementation plus a whole lot of other bells and whistles.

Yes, I would trust it for something like web server. But I would yet
have to see a portable GUI application in Java.

Thanks

Michal

···

On 06/12/2007, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

13

Michal Suchanek wrote:

Free if you happen to have the right platform ..

Yeah, if your platform is Linux, Windows, or Solaris...that's a pretty wide selection. And these days, there's Sun and non-Sun builds for BSD flavors, OS X, and plenty more.

The Java 5 documentation used to have very onerous license. Have you
ever read it? Maybe the newer ones are better. I heard that Java 7
will be GPL but we are not there yet.

Java 7 is GPL. The only pieces that aren't are the ones Sun had no rights to GPL, and they're in the process of being replaced with bits from e.g. GCJ.

Where is a complete Java 5 implementation other than Sun JVM? With the
GUI stuff and all? Everywhere I always see "Sun JRE required". Sure
the situation would be different for server stuff or other
applications where the fancy GUI is not required.

IBM has had complete Java 5 implementations for a while and now has a Java 6 beta out: IBM Developer

BEA has Java 5 and Java 6 implementations:http://dev2dev.bea.com/jrockit/

Apple of course has complete implementations of Java 1.4, Java 5, and non-public (any more, at least) betas of Java 6

Apache has milestone builds of Harmony 5.0: http://harmony.apache.org/

And there are a number of in-progress but working ports of the Java 6 research-licensed source and the GPLed Java 7 source.

All of these have GUI support. And I know that Sun's, IBM's, BEA's, and some of the other FOSS impls can run JRuby. Hell, JRuby on Rails can run on a mainframe running Z/OS using one of IBM's JDKs, and still talk to a Microsoft SQL Server database without modification. Do you want more?

When we are talking about Swing frameworks it is something Java, and
probably even Sun JVM specific. How can you abstract Java out then?

I think "probably" is the key word here that you're missing a lot of facts. Swing is nowhere near Sun JVM specific. It's supported by any Java SE implementation, and I've already listed several. Where are you getting this information?

And Swing is just an API. Sure, it's written in Java. But it's just bytecode in the end. From Ruby, it's just classes and methods:

   frame = JFrame.new("Some title")
   button = JButton.new("Press me")

   frame.set_size 300, 300
   frame.always_on_top = true
   frame.add button

   button.add_action_listener { button.text = "Pressed!" }

   frame.show

This is all plain old JRuby code, and can be packaged up WITH JRuby in a single file that runs on any Java 5+ implementation without rebuilding or repackaging in any way. How is that not cool?

Specifically with libc some common systems allow to install several
libc version, and the right is picked for running the application.
However, Java application for different version of JVM just breaks.

I have five Java SE versions installed on my machine. Four are from Apple and one is a port of the Java 6 source. I switch between them freely. Sure, if I compile for Java 6 and try to run on Java 4, it will break; that's by design, so I can write to Java 6 APIs and know that if the app starts up it has guarantees about compatibility across all APIs. And a user only needs to know one version number to be sure the app will run rather than having to track a dozen library versions potentially incompatible with each other or their own past versions.

And backward-compatibility on the Java platform is far better than almost every other platform I've used; even Ruby 1.9 is going to break many uses of String, block arguments, and other features (for the better, I must say). Perhaps it's a matter of opinion when a bad API is fixed as to whether it's a good fix or a breaking change; but that's no different from any other platform.

But I think we're getting too far away from Ruby here. You're set in your ways and not going to change your opinion or give the Java platform another chance. I can sympathize with folks who've been burned by the platform; I lived through those days as a Java developer, which is a large part of the reasons why I work on JRuby. But times change, and the platform hasn't stood still. If you continue to live with outdated prejudices, you're going to miss out on an outstanding VM. And in my opinion, you're going to miss out on a great implementation of Ruby as well.

Do as you will.

- Charlie