Package requests for the prelim. Ruby Production Archive

Discussion in 'Ruby' started by Mauricio Fernández, Aug 21, 2004.

  1. As of today, 110 libraries/applications are available in
    the prelim. repository of the Ruby Production Archive (see
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software); I have
    packaged all the "top-sellers" in Rubyforge and several lesser-known
    programs.

    I need your help to prioritize the remaining sw., and would hence
    appreciate some feedback:
    (1) which lib/app would you like to see packaged?
    (2) do you want binaries? If so, for which platform (I expect win32 to be
    the predominant answer, plz specify which runtime/"Ruby distro")

    You can place your answer to (1) in
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?Package_Requests

    thx

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 21, 2004
    #1
    1. Advertising

  2. Mauricio Fernández

    Dave Thomas Guest

    On Aug 21, 2004, at 12:38, Mauricio Fernández wrote:

    >
    > As of today, 110 libraries/applications are available in
    > the prelim. repository of the Ruby Production Archive (see
    > http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software); I have
    > packaged all the "top-sellers" in Rubyforge and several lesser-known
    > programs.


    You should probably remove RDoc, as it is bundled with Ruby. Installing
    a parallel version will confuse things, and may well break existing
    documentation.


    Cheers

    Dave
    Dave Thomas, Aug 21, 2004
    #2
    1. Advertising

  3. On Sun, Aug 22, 2004 at 03:06:29AM +0900, Dave Thomas wrote:
    >
    > On Aug 21, 2004, at 12:38, Mauricio Fernández wrote:
    >
    > >
    > >As of today, 110 libraries/applications are available in
    > >the prelim. repository of the Ruby Production Archive (see
    > >http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software); I have
    > >packaged all the "top-sellers" in Rubyforge and several lesser-known
    > >programs.

    >
    > You should probably remove RDoc, as it is bundled with Ruby. Installing
    > a parallel version will confuse things, and may well break existing
    > documentation.


    That (breakage) won't happen ;)

    The package is misnamed. I should have called it ri-rpa-support;
    it is not a complete rdoc, just provides support for ri-rpa, and can
    coexist with the normal rdoc. At any rate, were it to conflict with
    the normal one (which won't happen cause it's installed under rpa-rdoc/
    in sitelibdir), rpa-base would detect the conflict and prevent it.

    Regarding ri-rpa, I distribute it as a separate ri with some RPA-specific
    patches because I didn't want to force you to change anything in the
    one shipped with Ruby only to make things easier for RPA/rpa-base
    (*). No harm is done though because it operates independently from
    the standard one -- that's why I was redistributing parts of the rdoc
    'runtime' to make it work.

    Now, I hear the standard ri will be modified because otherwise RubyGems
    wouldn't be able to achieve real ri/rdoc integration. I hope this change
    is general enough to allow other systems to leverage it (besides RPA,
    other re-packagers like Debian/FreeBSD/etc could use it to provide
    system-wide documentation for Ruby software).

    If the RubyGems team doesn't do so, I could try to provide a patch to
    allow ri integration, independently from the package/port manager.

    IMHO it is important not to hinder the work of other re-packagers.

    (*) Since RPA/rpa-base has not been declared the Standard, I hesitate to
    ask 3rd parties to change their sw. to suit my needs. This is consistent
    with repackaging stuff myself instead of asking the developers to do it
    for me, which makes sense since RPA's goals are so much more ambitious
    than RubyGems'.

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 21, 2004
    #3
  4. Mauricio Fernández

    Dave Thomas Guest

    On Aug 21, 2004, at 13:49, Mauricio Fernández wrote:
    > The package is misnamed. I should have called it ri-rpa-support;
    > it is not a complete rdoc,


    Thanks - it would be great if you could rename it: having two different
    things both called RDoc is confusing.

    > Now, I hear the standard ri will be modified because otherwise RubyGems
    > wouldn't be able to achieve real ri/rdoc integration.


    That's news to me :) AFAIK, the gems team is using the off-the-shelf
    rdoc/ri.

    However, if there are features I could add that would help all you
    packaging folk, just let me know.

    Cheers

    Dave
    Dave Thomas, Aug 21, 2004
    #4
  5. On Sun, Aug 22, 2004 at 04:07:07AM +0900, Dave Thomas wrote:
    > >Now, I hear the standard ri will be modified because otherwise RubyGems
    > >wouldn't be able to achieve real ri/rdoc integration.

    >
    > That's news to me :) AFAIK, the gems team is using the off-the-shelf
    > rdoc/ri.
    >
    > However, if there are features I could add that would help all you
    > packaging folk, just let me know.


    I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

    #SOME WORK DONE Figure out what to do about "ri" integration. Dave
    is open to modifying ri itself if it doesn't have a negative impact
    on the existing ri functionality. MUCH better than creating ri-gems or
    some such crap

    (I do share the implicit "ri-rpa == crap" assessment :p, but it exists
    currently as a sub-optimal solution for the reasons stated in my
    prev. msg)

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 21, 2004
    #5
  6. Mauricio Fernández

    Dave Thomas Guest

    On Aug 21, 2004, at 14:44, Mauricio Fernández wrote:

    > On Sun, Aug 22, 2004 at 04:07:07AM +0900, Dave Thomas wrote:
    >>> Now, I hear the standard ri will be modified because otherwise
    >>> RubyGems
    >>> wouldn't be able to achieve real ri/rdoc integration.

    >>
    >> That's news to me :) AFAIK, the gems team is using the off-the-shelf
    >> rdoc/ri.
    >>
    >> However, if there are features I could add that would help all you
    >> packaging folk, just let me know.

    >
    > I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:
    >
    > #SOME WORK DONE Figure out what to do about "ri" integration. Dave
    > is open to modifying ri itself


    I don't think you need feel misled; Chad's statement is inconsistent
    with what I said you you earlier: I _am_ open to suggestions from both
    the gems folks and the rpa folks on things that would make integration
    with their projects easier. Right now, the gems folks appear not to
    need anything extra (I chatted with Chad about this for a while), but
    if they change their minds, I'll listen. Similarly if the rpa folks
    want new features, they just need to ask.

    My only constraint is that any change we make shouldn't hurt rdoc/ri in
    general. The major stumbling block to all of the packaging systems that
    I see is handling installed packages that extend existing classes.
    These work fine on installation, but I don't know how to handle the
    uninstall, as stuff from the package may have been added to preexisting
    descriptions.

    Cheers

    Dave
    Dave Thomas, Aug 21, 2004
    #6
  7. On Sun, Aug 22, 2004 at 04:55:21AM +0900, Dave Thomas wrote:
    > My only constraint is that any change we make shouldn't hurt rdoc/ri in
    > general. The major stumbling block to all of the packaging systems that
    > I see is handling installed packages that extend existing classes.
    > These work fine on installation, but I don't know how to handle the
    > uninstall, as stuff from the package may have been added to preexisting
    > descriptions.


    Yes, that's the fundamental problem (and some associated usability issues)
    I would like to solve in a general way. It might require some non-trivial
    changes to ri/rdoc though... I'll try to explore some possibilities in
    ri-rpa, prior to a possible merge.

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 21, 2004
    #7
  8. On 8/21/04 3:44 PM, "Mauricio Fernández" <> wrote:

    > On Sun, Aug 22, 2004 at 04:07:07AM +0900, Dave Thomas wrote:
    >>> Now, I hear the standard ri will be modified because otherwise RubyGems
    >>> wouldn't be able to achieve real ri/rdoc integration.

    >>
    >> That's news to me :) AFAIK, the gems team is using the off-the-shelf
    >> rdoc/ri.
    >>
    >> However, if there are features I could add that would help all you
    >> packaging folk, just let me know.

    >
    > I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:


    You were misled? This is just some notes that I typed up relayed from Chad
    on some final things we wanted to get done...not a general communications to
    the broader community. No problem with reading it obviously but don't take
    it as a message. The below mentioned item says Dave is open to changing
    ri...in general...based on community feedback...he always has been. We can
    obviously add our own version of ri, but we did not like the idea. Don't
    take it personally :)

    >
    > #SOME WORK DONE Figure out what to do about "ri" integration. Dave
    > is open to modifying ri itself if it doesn't have a negative impact
    > on the existing ri functionality. MUCH better than creating ri-gems or
    > some such crap
    >
    > (I do share the implicit "ri-rpa == crap" assessment :p, but it exists
    > currently as a sub-optimal solution for the reasons stated in my
    > prev. msg)
    Richard Kilmer, Aug 21, 2004
    #8
  9. On Sun, Aug 22, 2004 at 05:20:28AM +0900, Richard Kilmer wrote:
    > > I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

    [...]
    > Don't take it personally :)


    I should have emphasized the smiley :))

    > > #SOME WORK DONE Figure out what to do about "ri" integration. Dave
    > > is open to modifying ri itself if it doesn't have a negative impact
    > > on the existing ri functionality. MUCH better than creating ri-gems or
    > > some such crap
    > >
    > > (I do share the implicit "ri-rpa == crap" assessment :p, but it exists

    ====
    > > currently as a sub-optimal solution for the reasons stated in my
    > > prev. msg)


    No offense taken :)

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 21, 2004
    #9
  10. Mauricio Fernández

    Chad Fowler Guest

    On Sun, 22 Aug 2004 05:20:28 +0900, Richard Kilmer <> wrote:
    >
    >
    >
    > On 8/21/04 3:44 PM, "Mauricio Fernández" <> wrote:
    >
    > > On Sun, Aug 22, 2004 at 04:07:07AM +0900, Dave Thomas wrote:
    > >>> Now, I hear the standard ri will be modified because otherwise RubyGems
    > >>> wouldn't be able to achieve real ri/rdoc integration.
    > >>
    > >> That's news to me :) AFAIK, the gems team is using the off-the-shelf
    > >> rdoc/ri.
    > >>
    > >> However, if there are features I could add that would help all you
    > >> packaging folk, just let me know.

    > >
    > > I was misled by http://rubygems.rubyforge.org/wiki/wiki.pl?ChadsList:

    >
    > You were misled? This is just some notes that I typed up relayed from Chad
    > on some final things we wanted to get done...not a general communications to
    > the broader community. No problem with reading it obviously but don't take
    > it as a message. The below mentioned item says Dave is open to changing
    > ri...in general...based on community feedback...he always has been. We can
    > obviously add our own version of ri, but we did not like the idea. Don't
    > take it personally :)
    >
    >


    Right. This wasn't meant to be a dig. ri-gems and ri-rpa are
    obviously suboptimal solutions. Uninstall remains an issue, but we
    may be willing to just make that compromise. After all, it's an
    inherent (and IMO acceptable) limitation of the way ri works right
    now. A major reason we don't think/hear about it much is that there
    is no obvious, clean way to uninstall libraries when not using a
    system like RubyGems or RPA-base.

    As for ambition, don't be so quick to judge. Wait until this time
    next year.... ;)
    Chad Fowler, Aug 22, 2004
    #10
  11. Doesn't ri have a problem if two parts of the class are defined in
    --ri-system and --ri-site, much less a "local" directory?

    -austin
    Austin Ziegler, Aug 22, 2004
    #11
  12. On Sun, Aug 22, 2004 at 05:20:28AM +0900, Richard Kilmer wrote:
    > You were misled? This is just some notes that I typed up relayed from Chad
    > on some final things we wanted to get done...not a general communications to
    > the broader community. No problem with reading it obviously but don't take
    > it as a message. The below mentioned item says Dave is open to changing
    > ri...in general...based on community feedback...he always has been. We can
    > obviously add our own version of ri, but we did not like the idea. Don't
    > take it personally :)


    mmmm I was wondering why both you & Dave were attaching such an
    importance to the word 'misled'. It seems my condition of non-native
    English speaker might well be the culprit :)

    dictionary.com returns

    mis·lead ( P ) Pronunciation Key (ms-ld)
    tr.v. mis··led, (-ld) mis·lead·ing, mis·leads

    1. To lead in the wrong direction.
    2. To lead into error of thought or action, especially by intentionally
    deceiving. See Synonyms at deceive.

    For the record, I obviously meant a softer (1)... I didn't want to imply
    that you deliberately deceived me on purpose; I was just confused. I
    didn't mean to blame you for that :)

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 22, 2004
    #12
  13. Mauricio Fernández

    Dave Thomas Guest

    On Aug 21, 2004, at 22:08, Austin Ziegler wrote:

    > Doesn't ri have a problem if two parts of the class are defined in
    > --ri-system and --ri-site, much less a "local" directory?


    Yup! Currently it assumes that any one class is defined in one place,
    as I hadn't anticipated that
    the packaging folks would install into many different documentation
    directories. When I get this book project finished, I'll be trying to
    work with anyone who's interested to change this behavior to better
    suit their models.


    Cheers

    Dave
    Dave Thomas, Aug 22, 2004
    #13
  14. On Sun, 22 Aug 2004 23:00:08 +0900, Dave Thomas <> wrote:
    > On Aug 21, 2004, at 22:08, Austin Ziegler wrote:
    > > Doesn't ri have a problem if two parts of the class are defined in
    > > --ri-system and --ri-site, much less a "local" directory?

    > Yup! Currently it assumes that any one class is defined in one place,
    > as I hadn't anticipated that
    > the packaging folks would install into many different documentation
    > directories. When I get this book project finished, I'll be trying to
    > work with anyone who's interested to change this behavior to better
    > suit their models.


    Right. I think that this is something that can be dealt with
    regardless of the model by the use of a (for lack of a better term)
    RI_PATH similar to MAN_PATH. Then, RPA and RubyGems can add to or
    remove from a standard RI_PATH location "at will" (or locations; I
    would suggest that the RI_PATH could be stored in the site directory,
    the system directory, and optionally the "local" directory).

    Right now, without even using one of the main packaging systems, I can do:

    % rdoc --ri-system diff/lcs

    If I have previously run rdoc/ri generation for Ruby as a whole to
    --ri-site, then when I do "ri Array", I will no longer be able to see
    the general ri documentation for Array (because Diff::LCS includes an
    extension to Array). (There also appears to be a problem with merging
    last time I checked this; I think I sent a patch that should fix that,
    though. Merging should be the default) I think that it will also cause
    problems if I generate the ri documentation in the "local/home"
    directory.

    As long as ri knows where to find various YAML files (e.g., RI_PATH),
    then whatever solution is used to fix the existing problem will fix
    the problem for packagers.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Aug 22, 2004
    #14
  15. Mauricio Fernández

    James Britt Guest

    I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.

    First, it keeps asking me to modify the installation prefix, although on
    each step the prefix is really just a variation on what has gone before;
    you'd think it would keep track of what I just entered and use that to
    derive the next path option. But no matter. Even after explicitly
    entering the paths, the installation fails.

    (Here I'm trying to install the packages into c:/ruby-rpa/ and related
    subdirectories)

    c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
    c:/ruby-rpa/c: (Errno::EINVAL)

    Has this been tested on Windows? Is it not meant for Windows users?

    Thanks,

    James

    P.S.

    A recent blog entry at
    http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
    says,

    "I have invited the people from ruby-talk to request packages for the
    Ruby Production Archive. So far the response has been a bit
    disappointing; seemingly no Rubyist wants to use software packaged with
    some care, or maybe it’s just that the 114 packages currently available
    cover all needs?"

    I'm sure Mauricio meant no disrespect, but this seems to imply that
    packages currently available from RubyForge and elsewhere are *not*
    packaged with some care. No doubt some of these *are* fairly
    half-assed, but there may be many other reasons why people prefer not to
    use rpa; poor Windows support being a real possibility.
    James Britt, Aug 22, 2004
    #15
  16. Mauricio Fernández

    Aredridel Guest

    > A recent blog entry at
    > http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
    > says,
    >
    > "I have invited the people from ruby-talk to request packages for the
    > Ruby Production Archive. So far the response has been a bit
    > disappointing; seemingly no Rubyist wants to use software packaged with
    > some care, or maybe it¢s just that the 114 packages currently available
    > cover all needs?"


    It's damn good! A fair bit ahead of where I am. Everything I currently
    use is in there, my own ruby-xattr aside.

    > I'm sure Mauricio meant no disrespect, but this seems to imply that
    > packages currently available from RubyForge and elsewhere are *not*
    > packaged with some care. No doubt some of these *are* fairly
    > half-assed, but there may be many other reasons why people prefer not to
    > use rpa; poor Windows support being a real possibility.


    I can testify as to the varying quality of the author's packaging. I've
    been working really hard on building RPM specs for Ruby packages for the
    PLD distro, and it's tough, slow going. Some things (notably using a
    modern setup.rb from Minero Aoki) are very easy. Others I've had to
    fight with a lot, trying to get them to comply with the Linux Filesystem
    Heirarchy Standard and other requirements. It's not easy.

    I'm looking forward to trying rpa-base soon -- I haven't had the time (I
    spent four hours trying to figure out why Ruby wouldn't compile on Sparc
    or Alpha processors, only to find it was the Oniguruma preview failing
    on some architectures)

    For RPA, I can see windows support being important. I imagine that
    limits its usage by about half.

    Ari
    Aredridel, Aug 22, 2004
    #16
  17. Mauricio Fernández

    David Ross Guest

    As mentioned in other emails. Windows is a target
    platform for it to work on. RPA-base might be a
    development release, but it works very well.

    Batsman: Work work work :)




    --- Aredridel <> wrote:

    > > A recent blog entry at
    > >

    >

    http://www.thekode.net/blog/Tech/Ruby/rpa-packages.html
    > > says,
    > >
    > > "I have invited the people from ruby-talk to

    > request packages for the
    > > Ruby Production Archive. So far the response has

    > been a bit
    > > disappointing; seemingly no Rubyist wants to use

    > software packaged with
    > > some care, or maybe it¢s just that the 114

    > packages currently available
    > > cover all needs?"

    >
    > It's damn good! A fair bit ahead of where I am.
    > Everything I currently
    > use is in there, my own ruby-xattr aside.
    >
    > > I'm sure Mauricio meant no disrespect, but this

    > seems to imply that
    > > packages currently available from RubyForge and

    > elsewhere are *not*
    > > packaged with some care. No doubt some of these

    > *are* fairly
    > > half-assed, but there may be many other reasons

    > why people prefer not to
    > > use rpa; poor Windows support being a real

    > possibility.
    >
    > I can testify as to the varying quality of the
    > author's packaging. I've
    > been working really hard on building RPM specs for
    > Ruby packages for the
    > PLD distro, and it's tough, slow going. Some things
    > (notably using a
    > modern setup.rb from Minero Aoki) are very easy.
    > Others I've had to
    > fight with a lot, trying to get them to comply with
    > the Linux Filesystem
    > Heirarchy Standard and other requirements. It's not
    > easy.
    >
    > I'm looking forward to trying rpa-base soon -- I
    > haven't had the time (I
    > spent four hours trying to figure out why Ruby
    > wouldn't compile on Sparc
    > or Alpha processors, only to find it was the
    > Oniguruma preview failing
    > on some architectures)
    >
    > For RPA, I can see windows support being important.
    > I imagine that
    > limits its usage by about half.
    >
    > Ari
    >
    >
    >
    >
    >
    >


    ----------------------------------------
    -- Name: David Ross
    -- Phone: 865.539.3798
    -- Email: drossruby [at] yahoo [dot] com
    ----------------------------------------



    _______________________________
    Do you Yahoo!?
    Win 1 of 4,000 free domain names from Yahoo! Enter now.
    http://promotions.yahoo.com/goldrush
    David Ross, Aug 22, 2004
    #17
  18. On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
    > I just tried to install rpa-base-0.2.0b on a Win2K machine, with no luck.
    >
    > First, it keeps asking me to modify the installation prefix, although on
    > each step the prefix is really just a variation on what has gone before;
    > you'd think it would keep track of what I just entered and use that to
    > derive the next path option. But no matter. Even after explicitly
    > entering the paths, the installation fails.
    >
    > (Here I'm trying to install the packages into c:/ruby-rpa/ and related
    > subdirectories)
    >
    > c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
    > c:/ruby-rpa/c: (Errno::EINVAL)
    >
    > Has this been tested on Windows? Is it not meant for Windows users?


    It has been tested on Win32. I myself have tried it on WinXP and it
    worked fine there (I've often installed instiki in a couple minutes and
    verified it ran fine for instance; I also installed Rails that way and
    toyed with it, using the WEBrick dispatcher).

    I believe you triggered a bug in the bootstrap phase related to the use
    of a $prefix different from the one Ruby is installed under.

    Could you try to install it under c:\ruby (you can later remove it with
    rpa remove rpa-base and nothing will have been modified) to confirm
    this? This should be safe since rpa-base will not overwrite anything
    unless you tell it explicitly that it's ok (--force), and installations
    are atomic.

    I'll look into the possible bug and hopefully solve it soon.

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 22, 2004
    #18
  19. On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
    > (Here I'm trying to install the packages into c:/ruby-rpa/ and related
    > subdirectories)
    >
    > c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
    > c:/ruby-rpa/c: (Errno::EINVAL)


    Thank you for your report. It helped me find a stupid bug which was triggered
    when one didn't use ruby's own $prefix.

    Since the issue affects the bootstrapping phase (i.e. can't be fixed
    with a normal self-upgrade), I have decided to release 0.2.1pre1, available
    at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
    your problems.

    Please keep in mind the following:
    * when answering to the questions in the bootstrap phase, only the first
    path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
    normally on win32). The others are relative to the former and the
    default values should be perfectly fine.
    * setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
    put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
    and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
    but not 100% sure).
    As of now, it is probably better to just install into the normal
    $prefix, since rpa-base provides enough guarantees to make sure it
    won't end up cluttered with half-installed RPA ports.
    Support for per-user installations is planned and might be done in
    time for 0.3.0.

    For your reference, here's the patch that fixes the problem you
    reported, I believe.

    --- lib/rpa/helper.rb (revision 765)
    +++ lib/rpa/helper.rb (revision 766)
    @@ -471,7 +471,7 @@
    def run(installer)
    super
    sitelibdir = ::Config::CONFIG["sitelibdir"]
    - sitelibdir.gsub!(/^#{Regexp.escape @config["prefix"]}/, "")
    + sitelibdir.gsub!(/^#{Regexp.escape:):Config::CONFIG["prefix"])}/, "")
    do_copy(installer, sitelibdir)
    end


    > there may be many other reasons why people prefer not to
    > use rpa; poor Windows support being a real possibility.


    There are good reasons for using both RubyGems and rpa-base, and you
    can indeed use them both at a time.

    I am sure more bugs will be found in rpa-base's codebase, just as in
    any other piece of sw.; I believe the bases are solid, though (I haven't
    touched the transactional code lately, but last time I did the count was
    at 500000 successful transactions since the last real bug in that area).
    So far I've managed to fix all reported bugs in under 1-2 days (those
    that were reported via IRC were typically fixed within a few hours).

    Now, regarding my original question, is there anything you'd like to
    see packaged? ;-)

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 22, 2004
    #19
  20. Mauricio Fernández

    James Britt Guest

    Mauricio Fernández wrote:
    > On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
    >
    >>(Here I'm trying to install the packages into c:/ruby-rpa/ and related
    >>subdirectories)
    >>
    >>c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
    >>c:/ruby-rpa/c: (Errno::EINVAL)

    >
    >
    > Thank you for your report. It helped me find a stupid bug which was triggered
    > when one didn't use ruby's own $prefix.


    Sweet. Thanks.
    >
    > Since the issue affects the bootstrapping phase (i.e. can't be fixed
    > with a normal self-upgrade), I have decided to release 0.2.1pre1, available
    > at http://rubyforge.org/frs/?group_id=265. Please tell me if it solves
    > your problems.
    >
    > Please keep in mind the following:
    > * when answering to the questions in the bootstrap phase, only the first
    > path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
    > normally on win32). The others are relative to the former and the
    > default values should be perfectly fine.


    Ah. I thought the default paths, as presented by the installer, were
    complete paths. So I kept entering complete paths. The prompts gave no
    indication that my earlier paths would be reused to build the other paths.

    > * setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
    > put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
    > and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
    > but not 100% sure).
    > As of now, it is probably better to just install into the normal
    > $prefix, since rpa-base provides enough guarantees to make sure it
    > won't end up cluttered with half-installed RPA ports.


    Are you *sure*? I've had enough issues with
    installing/uninstalling/reinstalling assorted versions of the 1-click
    package. I don't want any overlap between this and my main ruby
    installation.


    > Support for per-user installations is planned and might be done in
    > time for 0.3.0.


    Nice.

    ...

    >
    >>there may be many other reasons why people prefer not to
    >>use rpa; poor Windows support being a real possibility.

    >
    >
    > There are good reasons for using both RubyGems and rpa-base, and you
    > can indeed use them both at a time.
    >
    > I am sure more bugs will be found in rpa-base's codebase, just as in
    > any other piece of sw.; I believe the bases are solid, though (I haven't
    > touched the transactional code lately, but last time I did the count was
    > at 500000 successful transactions since the last real bug in that area).
    > So far I've managed to fix all reported bugs in under 1-2 days (those
    > that were reported via IRC were typically fixed within a few hours).
    >
    > Now, regarding my original question, is there anything you'd like to
    > see packaged? ;-)


    I don't know yet. I need to see how much disk space this takes up as
    is, and see what's installed, and what I might use. You've probably
    covered all the things I need. I have a few alpha/beta projects on
    rubyforge. They tend have been created to scratch a personal itch, so
    if they're not currently on your list then it's unlikely there is much
    demand for them.

    I'll go see if I can get this to play well on my laptop.

    Thanks,

    James
    James Britt, Aug 22, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fernando Arámburu

    web requests and mobile requests

    Fernando Arámburu, Apr 8, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    432
    Joerg Jooss
    Apr 8, 2005
  2. Mauricio Fernández
    Replies:
    1
    Views:
    292
    Simon Strandgaard
    Aug 6, 2004
  3. Premshree Pillai

    Ruby script archive

    Premshree Pillai, Jan 25, 2005, in forum: Ruby
    Replies:
    0
    Views:
    88
    Premshree Pillai
    Jan 25, 2005
  4. Dan Bikle
    Replies:
    2
    Views:
    139
    gabriele renzi
    Oct 26, 2005
  5. Jayson Williams

    How do I create an RBA Ruby Archive File?

    Jayson Williams, Sep 18, 2007, in forum: Ruby
    Replies:
    11
    Views:
    222
    Alex Fenton
    Sep 24, 2007
Loading...

Share This Page