Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Ruby (http://www.velocityreviews.com/forums/f66-ruby.html)
-   -   Package requests for the prelim. Ruby Production Archive (http://www.velocityreviews.com/forums/t816283-package-requests-for-the-prelim-ruby-production-archive.html)

Mauricio Fernández 08-21-2004 05:38 PM

Package requests for the prelim. Ruby Production Archive
 

As of today, 110 libraries/applications are available in
the prelim. repository of the Ruby Production Archive (see
http://rpa-base.rubyforge.org/wiki/w...ged_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/w...ckage_Requests

thx

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com




Dave Thomas 08-21-2004 06:06 PM

Re: Package requests for the prelim. Ruby Production Archive
 

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/w...ged_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





Mauricio Fernández 08-21-2004 06:49 PM

Re: Package requests for the prelim. Ruby Production Archive
 
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/w...ged_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




Dave Thomas 08-21-2004 07:07 PM

Re: Package requests for the prelim. Ruby Production Archive
 

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





Mauricio Fernández 08-21-2004 07:44 PM

Re: Package requests for the prelim. Ruby Production Archive
 
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




Dave Thomas 08-21-2004 07:55 PM

Re: Package requests for the prelim. Ruby Production Archive
 

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





Mauricio Fernández 08-21-2004 08:17 PM

Re: Package requests for the prelim. Ruby Production Archive
 
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




Richard Kilmer 08-21-2004 08:20 PM

Re: Package requests for the prelim. Ruby Production Archive
 



On 8/21/04 3:44 PM, "Mauricio Fernández" <batsman.geo@yahoo.com> 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)







Mauricio Fernández 08-21-2004 08:33 PM

Re: Package requests for the prelim. Ruby Production Archive
 
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




Chad Fowler 08-22-2004 12:27 AM

Re: Package requests for the prelim. Ruby Production Archive
 
On Sun, 22 Aug 2004 05:20:28 +0900, Richard Kilmer <rich@infoether.com> wrote:
>
>
>
> On 8/21/04 3:44 PM, "Mauricio Fernández" <batsman.geo@yahoo.com> 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.... ;)





All times are GMT. The time now is 06:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.