From: James Britt <jamesUNDERBARb@...>
Date: 2004-11-10T09:32:43+09:00
Subject: Re: [ANN] Catapult 0.1.0 Released

Mauricio Fern�ndez wrote:
> On Wed, Nov 10, 2004 at 02:50:09AM +0900, James Britt wrote:
> 
>>So, as a gem, installing catapult into the gem dirs is fine, as running
>>Catapult via some caller script (e.g. launch.rb ) is arguably the better
>>way to run it.  But I don't think that launch.rb should go into a gems
>>dir; $HOME/bin or /usr/local/bin or something along those lines seems
>>more appropriate.
>>
>>I can write a simple installer script that does this, I just haven't
>>been motivated.  But I don't think gems or rpa manages selective
>>placement of apps based on user choice.   I believe they treat
>>everything as something to install in the Ruby libs|gems directories.
> 
> 
> rpa-base doesn't force you to install into Ruby's libdir or a "gem-style"
> directory: it can manage files in arbitrary paths under $prefix (typically
> /usr or /usr/local). Also, RubyGems addresses this issue by creating
> a stub in bin/. So what are exactly your needs; just placing launch.rb
> into $prefix/bin or equivalent?
> 
> I am very interested in special needs as far as packaging is concerned;
> one of the reasons why more than 140 libs/apps have been packaged for
> RPA so far was to make sure that rpa-base could handle them.

In this case, the user should be able to decide where launch.rb ends up. 
  One option is to leave it in the same directory from where the 
installation is done.  Another (which I prefer) is to prompt the user 
for a directory, with some default value (either the current dir, or the 
OS equivalent of  /usr/local/bin).  The main code can just go into some 
dir in the Ruby load path.

If the user is doing an upgrade, then the installation of launch.rb 
should be mindful of not erasing user settings.  The current code is 
likely not well designed for easy merging of new source with old 
settings; grabbing the text after __END__ is easy, but (maybe) not so 
for parameters being passed to Catapult.new.  On the other hand, there 
really should not be much code changing in the launch script.  (And 
writing this now makes me see that there is code in launch.rb that 
should be moved into catapult.rb or some other file so that launch.rb 
does not contain anything other a call to start the app with a set of 
parameters and environment settings.  As-is there is too much mingling 
of bodily fluids.)

So, simplest-case requirements: put libs into ruby load path, and the 
launch script at a user-prompted location, asking for permission before 
overwriting an existing launch script, or renaming the old launch script 
before installing a new one, and merging any configuration details into 
the new launch script.

Thanks,


James