Re: Gems as key? Re: The real Ruby vs. Python.

Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.

And that means putting RPAN (or whatever) as part of the Ruby standard
library, having college mirrors, doing dependancy checking, and so
forth.

On Thu, 28 Oct 2004 01:12:24 +0900, David Ross <dross@[EMAIL PROTECTED]
>
wrote:
> Its Me wrote:
> 
> 
> 
> >"Abe Vionas_MailingList" <mailinglist_abe@[EMAIL PROTECTED]
> wrote
> >
> >
> >
> >>What it comes down to is what it's coming down to for
> >>me... platform maturity.
> >>
> >>
> >
> >This bites me quite often as well, though I have not given up. There
are
> >likely hordes of unwashed m***** like me, not entirely adept at
> >source-patch-recompile-rebuild, who never even get started with Ruby
because
> >of the kinds of issues Abe describes.
> >
> >Their loss or Ruby's? Unfortunately, probably both.
> >
> >I feel gems is one of the keys to getting past this. Gems can make my
local
> >(Windows) Ruby install feel like
> >  - a single plug-in system
> >  - pulling together 'requires'
> >  - incor****ating do***entation from a single starting point
> >  - including compatible versions and dependencies
> >
> >It would be great if gems was part of the standard Ruby distribution,
if RPA
> >could use gems as its underlying package manager (reducing confusion
for
> >newBs), and if RPA could then also take on the role of Release Manager
for
> >Ruby itself.
> >
> >Some misc thoughts:
> >
> >- Could gems ALSO cover binaries AND binary/library dependencies?
> >
> >- Could the gems RDOCs have links to some gems-aligned community
> >do***entation site, as someone else proposed here recently?
> >
> >
> >
> >
> >
> >
> >
> RPA and RubyGems have different aspects in implementation, so it would
> not be compatible/easy. Now that I have a RPA QA team for windows, we
> should have binaries put together soon. Good sup****t for software. :)
> 
> David Ross
> --
> Hazzle free packages for Ruby?
> RPA is available from http://www.rubyarchive.org/
> 
>