best way to distribute?

[Pavel Pvl]

hi, what is the best way to distribute ruby apps without having the end
user need to download ruby?

i have looked into:
tar2ruby
exerb
and Xruby

however they seem difficult to use, after trying and failing. are there
other solutions? or any guides? for such an amazing language, ruby is
very difficult to compile to a standalone.

 

[Pavel Pvl]

i forgot to mention im usign debian linux and can anyone tell me what
init.rb referres to?

 

[Joel VanderWerf]

hi, what is the best way to distribute ruby apps without having the end
user need to download ruby?

rubyscript2exe is nice.

 

[Joe]

I asked almost the same question not too long ago. I think the
consensus was that JRuby was the best way to go. I don't really like
this solution, but seems like the only way to go at the moment.

Joe

 

[Pavel Pvl]

well it seems as tho i can;t really figure out how to use
rubyscript2exe, but i emailed the creator. im still trying to get jruby
to work. But seriously for such a language, it's hard to believe that
there isn't any 'standard' compiler.

 

[Joe]

I found this hard to believe too.

I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.

 

[Joel VanderWerf]

I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.

If you want to package a set of pure ruby files (no extensions, no
interpreter) into a single script file, you can try darb:

http://raa.ruby-lang.org/project/darb/
http://redshift.sourceforge.net/darb/

Not as fancy as jar, and limited, but useful in some cases.

 

[Jeremy McAnally]

Ruby is an interpreted language at this point, so you have no choice
but to pair it with an interpreter of some kind, whether it be MRI
Ruby, Rubinius, JRuby, or whatever.

You could always just package a no-install version of Ruby with your
application, stripping out any libraries you don't use. You could
also look into somehow using miniruby:
http://article.gmane.org/gmane.comp.lang.ruby.general/68084

--Jeremy

I found this hard to believe too.

I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

 

[Ron Fox]

This is more to the 'gods of ruby' than a reply. Tcl/Tk has a nice
way to do stuff like this called Starpacks. This is possible using
the Tcl/Tk virtual file system hooks. Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.

A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:

http://www.equi4.com/papers/skpaper1.html

if any of the ruby gods are interested.

Please don't read this as a Tcl/Tk plug... just a comment that other
scripted languages had to face this and here's one solution that another
scripting language came up with that may apply here.

Ron.

 

[Adam Shelly]

Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.

A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:

Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/

 

[Cameron McBride]

Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/

Sounds like it to me, although I don't know starpacks at all.

I've had very good luck with rubyscript2exe. Even used it with C
extensions (like rb-gsl) and it worked on different distributions than
what I "compiled" it on.

Pavel, it's really straight-forward to use. What are you having
problems with?

Cameron

 

[mdiam]

On Dec 20, 2007 1:45 PM, Adam Shelly <adam.she...@gmai

Sounds like it to me, although I don't know starpacks at all.

I've had very good luck with rubyscript2exe. Even used it with C
extensions (like rb-gsl) and it worked on different distributions than
what I "compiled" it on.

Pavel, it's really straight-forward to use. What are you having
problems with?

Is there any working example of a macosx application (even some
"hello world") which is build with rubyscript2exe?

-- Maurice

 

[Ron Fox]

Some differentiations:
1. starpack/starkit technology also supports a separation of the
run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
in the VFS). This allows you to split the installer into a system
dependent piece (the tclkit) and the application (starkit). These can
be combined to a starpack which is system dependent.

2. Because the starkit part of the system is a full featured filesystem
from the Tcl/Tk point of view it's possible to do a few neat things
including automatic updating of the contents of the starkit. The
application, as it starts up can ask the world if there are newer
versions and, if desired, confirmed by the user..all the application
specific caveats you care to apply, can update itself in place.

3. Because the VFS that constitutes starkits is actually a metakit
database, updates described above can be done as a transaction which
either entirely succeed or entirely fail, but not leave the application
in some funky state.

4. Again, because the VFS is a file system, the application can:
- store data (e.g. ordinary help files) and access them as files.
- keep e.g. configuration data allowing for a portable computing env.
(e.g. a web-browser starpack could keep your book marks in its
VFS so you could run around with your browser on a memory stick).

5. Because the starkit is a virtual file system to Tcl/Tk, there's no
need to unpack the application into a temp directory for purely scripted
apps.. or for apps whose extensions are built into the tclkit. Only
compiled loadable extensions need to be copied out into the host's
filesystem so that they host system's dynamic loader can find them. For
large apps this can improve the startup time significantly.

Ron.

 

[Joe]

How does this handle interacting with the filesystem outside the VFS?
So let's say you have files in the same directory as the starkit How
would you access them? Does it automatically assume you're accessing
something outside of the starkit unless you specifically say you want
something in the starkit? (IIRC that's how jars work in Java)

Joe

 

[Charles Oliver Nutter]

Ruby is an interpreted language at this point, so you have no choice
but to pair it with an interpreter of some kind, whether it be MRI
Ruby, Rubinius, JRuby, or whatever.

You could always just package a no-install version of Ruby with your
application, stripping out any libraries you don't use. You could
also look into somehow using miniruby:
http://article.gmane.org/gmane.comp.lang.ruby.general/68084

Ruby 1.9, XRuby, IronRuby, Ruby.NET, and Rubinius run Ruby as compiled
bytecodes all the time (ok, you could say a bytecode interpreter, but
it's still a big step beyond walking an AST). JRuby includes a mixed
interpred/compiled mode for execution by default along with "all
interpreted" and "all compiled" modes. In fact, as far as I know, Ruby
1.8 is the only version that's "only" interpreted at this point...all
other versions have compiled execution.

- Charlie

 

[John Lam (DLR)]

Charles Oliver Nutter:

Ruby 1.9, XRuby, IronRuby, Ruby.NET, and Rubinius run Ruby as compiled
bytecodes all the time (ok, you could say a bytecode interpreter, but
it's still a big step beyond walking an AST). JRuby includes a mixed
interpred/compiled mode for execution by default along with "all
interpreted" and "all compiled" modes. In fact, as far as I know, Ruby
1.8 is the only version that's "only" interpreted at this point...all
other versions have compiled execution.

Actually, we've recently enabled an interpreted mode in IronRuby / DLR. We =
run interpreted by default until a method gets called multiple times, and t=
hen we compile. The exact heuristic hasn't been finalized yet, but we're fo=
rced to do this to do better on startup perf. The cost of JIT is rather exp=
ensive ...

-John

 

[Mark Roseman]

Sounds like it to me, although I don't know starpacks at all.

Hi Cameron,

No, starkits and starpacks are actually much more powerful and
versatile. The Tcl world had the equivalent of rubyscript2exe for years
and years, but when starkits and starpacks came out it everyone found it
a huge step forward when it came to deployment.

Among the advantages:
* ship a single file platform-specific executable (as per *2exe)
* ship a single file platform-neutral application, which can then be
run with a (single file) platform-specific but application-neutral
binary; in other words, your entire language runtime can be in a single
file you can just download, and use for many applications
* no changing your code... because starkits are based on a virtual
file system, you refer to files "in" the starkit exactly the same as you
would normal files on disk, using standard I/O commands. so that is
both scripts, data files, etc.
* starkits can be used as a way to distribute source, again all in
one file; people can grab the starkit, unpack it, make some changes,
pack it up again
* source can be optionally protected (i.e. you can't get the original
scripts back) using a compiler, which is actually a separate and
complementary tool

Mark

 

[Ron Fox]

The VFS appears mounted in a specific point on the actual filesystem.
There's no problem accessing files outside or inside the VFS.
I have a starkit, for example that implements a launcher for X11 clients
to windows X11 servers. That starkit is able to, and perfectly well
does, store session configurations in a file in the 'normal windows
locations $AppData\xlauncer'.

The application can find the top-level of the starkit vfs via the
variable starkit::topdir

See e.g. http://wiki.tcl.tk/4080

for more information and sample code.


Ron.

 

[Mark Roseman]

Joe, the virtual file system hooks work comparably to 'real' file
systems in that you can 'mount' a new file system at a particular point
in the directory tree.

Let's say you've downloaded your starkit to /home/foo/my.kit. When you
run the starkit, the file system inside it essentially gets mounted at
that location in the directory tree. So if you try to access
/home/foo/my.kit/bar/data.txt, that will look inside the starkit. If
you try to access /home/foo/other.dat, it will look in the regular file
system, because the starkit isn't mounted there.

So the nice thing is that it's all transparent. You just use the
regular commands you'd used to operate on any old file, and the internal
I/O system will figure out what 'filesystem' you're working on based
upon the path names.

Like any virtual file system based thing, the same approach is used for
other filesystems... e.g. one that maps an http server to a file system.

Mark

 

[Ron Fox]

I should once more say the intent is not to suggest that Tcl is
better than Ruby... but that the idea of using virtual file systems to
package
software is a good one that gives you a lot of traction, and one that
perhaps us ruby-ites could learn from, rather than struggling in the
wilderness for a few years before it occurs to us.
Looking at ruby2exe about the only thing it seems to be missing to
get there is the idea that it's internal tarball is really a virtual
filesystem, and could be accessed directly if ruby libraries had virtual
file system support.
The idea of virtual filesystems also provides much more than just
starpack/starkit technologies.

Ron.