[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: [ANN] Catapult 0.1.0 Released

Peña, Botp

11/9/2004 10:04:00 AM

James Britt [mailto:jamesUNDERBARb@neurogami.com] wrote:

//Catapult 0.1.0 has been released
//
//Catapult is a simple WEBrick instance that dynamically loads and
//executes objects defined by URL paths.

this can be very handy. do you have rpa for this?

kind regards -botp


6 Answers

James Britt

11/9/2004 2:13:00 PM

0

Peña, Botp wrote:

> James Britt [mailto:jamesUNDERBARb@neurogami.com] wrote:
>
> //Catapult 0.1.0 has been released
> //
> //Catapult is a simple WEBrick instance that dynamically loads and
> //executes objects defined by URL paths.
>
> this can be very handy. do you have rpa for this?

No. There is no packaging other than the tarball.

I've considered doing a gem, though I'm not sure if that is even worth it.

The code is a script that kicks off WEBrick; it think that makes it more
an application than a library. I call this script using a wrapper
script so that I can set environment variables, so in that context,
Catapult could be located as a Ruby lib. But, as a practical matter,
the launch.rb app would likely to live someplace outside of the Ruby lib
directories.

If there are any suggestions on a good way to do this (as a gem or an
rpa package, or both), please let me know. I've made gems, but no rpa
packages, so this would be of interest to me.


Thanks,

James



Austin Ziegler

11/9/2004 4:07:00 PM

0

On Tue, 9 Nov 2004 23:12:58 +0900, James Britt
<jamesunderbarb@neurogami.com> wrote:
> Peña, Botp wrote:
> > James Britt [mailto:jamesUNDERBARb@neurogami.com] wrote:
> > //Catapult 0.1.0 has been released
> > //
> > //Catapult is a simple WEBrick instance that dynamically loads and
> > //executes objects defined by URL paths.
> > this can be very handy. do you have rpa for this?
> No. There is no packaging other than the tarball.
>
> I've considered doing a gem, though I'm not sure if that is even worth it.
>
> The code is a script that kicks off WEBrick; it think that makes it more
> an application than a library. I call this script using a wrapper
> script so that I can set environment variables, so in that context,
> Catapult could be located as a Ruby lib. But, as a practical matter,
> the launch.rb app would likely to live someplace outside of the Ruby lib
> directories.
>
> If there are any suggestions on a good way to do this (as a gem or an
> rpa package, or both), please let me know. I've made gems, but no rpa
> packages, so this would be of interest to me.

Well ... I wrote an 18k management script for Ruwiki. It's probably
overkill, but some of the code could be made into a catapult launcher
deployment script.

Also, if Catapult itself is smart enough to run from the directory in
which it is started, then you probably don't even need that.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca



James Britt

11/9/2004 5:50:00 PM

0

Austin Ziegler wrote:

> On Tue, 9 Nov 2004 23:12:58 +0900, James Britt
> <jamesunderbarb@neurogami.com> wrote:
>
>>I've considered doing a gem, though I'm not sure if that is even worth it.
>>
>>The code is a script that kicks off WEBrick; it think that makes it more
>>an application than a library. I call this script using a wrapper
>>script so that I can set environment variables, so in that context,
>>Catapult could be located as a Ruby lib. But, as a practical matter,
>>the launch.rb app would likely to live someplace outside of the Ruby lib
>>directories.
>>
>>If there are any suggestions on a good way to do this (as a gem or an
>>rpa package, or both), please let me know. I've made gems, but no rpa
>>packages, so this would be of interest to me.
>
>
> Well ... I wrote an 18k management script for Ruwiki. It's probably
> overkill, but some of the code could be made into a catapult launcher
> deployment script.
>
> Also, if Catapult itself is smart enough to run from the directory in
> which it is started, then you probably don't even need that.

Catapult doesn't care where it starts. launch.rb calls "require
'catapult'", so from its pint of view, Catapult can be a library in the
Ruby load path.

The launch.rb code looks at text after __END__ to grab a list of
directories to append to ENV['CATAPULT_LOAD']. I found that relative
paths were tricky, because you start the script in a variety of ways.

I've changed the code so that all relative paths in the __END__ section
are treated as relative to launch.rb's directory.

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.

>
> -austin





Mauricio Fernández

11/9/2004 8:12:00 PM

0

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.

--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyar...


James Britt

11/10/2004 12:33:00 AM

0

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


Eivind Eklund

11/10/2004 5:13:00 PM

0

On Wed, 10 Nov 2004 09:32:43 +0900, James Britt
<jamesunderbarb@neurogami.com> wrote:
> Mauricio Fernández wrote:
> > On Wed, Nov 10, 2004 at 02:50:09AM +0900, James Britt wrote:
> > 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.

In FreeBSD ports, we generally install a .sample file for the stuff
the user is supposed to change, and then the user can copy that file.
This way, a deinstall and reinstall will not mess up anything the user
has configured.

The other option is to do a 3-way merge, mixing together the changes
the user has done and that's been done in RPA (like 'cvs update'
does).

Writing a special merge system for just this package seems like
overkill to me. Also, asking the user where to install stuff instead
of having them do a copy from a .sample file sounds fairly
inconvenient - it would block having multiple copies etc.

Eivind.
--
Hazzle free packages for Ruby?
RPA is available from http://www.rubyar...