From: David Masover <ninja@...>
Date: 2009-12-05T03:56:45+09:00
Subject: Re: Best way to distribute an app

On Friday 04 December 2009 11:08:17 am James Britt wrote:
> David Masover wrote:
> > On Monday 30 November 2009 09:03:28 am Omar Campos wrote:
> >>> 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.
> >
> > 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.

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 :)