From: Eivind Eklund Date: 2004-10-28T03:48:10+09:00 Subject: Re: Gems as key? Re: The real Ruby vs. Python. On Thu, 28 Oct 2004 01:09:05 +0900, Its Me wrote: > 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' > - incorporating documentation from a single starting point > - including compatible versions and dependencies The latter is a property of package repository administration, not of RubyGems. > 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), This is something we (the RPA team) consider infeasible; RubyGems does not have the capabilities we believe necessary. This is both in terms of RubyGems presently being less technically advanced than rpa-base, and in terms of one key capability: The ability for RPA to modify the technology to suit our needs. The key aspect of RPA is providing *maintainenance* for packages, and not just for the packaging. The idea is that you can take a "blessed" (core) RPA package, and you'll know: - That the packaged software itself is of reasonable quality - Security issues will be fixed - That as far as is reasonably possible, the code will be fixed for compatibility with newer versions of other packages - We'll do bugfixes of packages for newer versions of Ruby - There is a contact point for all the trivial little patches and bugfixes that make the difference between a "well worn" package and an annoying green one. This contact point remains even if the original author lost interest in the software This is a large task. The present rpa-base and package set only scratch the surface of what we're trying to do. We're presently looking at the next step in the enabling this: - A new version of rpa-base that support the development cycle for the above much better (integration with version control system to make maintenance of code uniform etc) - Documentation to help more people be able to do RPA packaging - Documentation and checklists for helping software quality - Building a review team for doing code review for code we import into the RPA - Support for binary packages, to make Ruby deployment on Windows etc easier - Increase in team size As this stuff gets done, we'll have more to do, of course. > and if RPA could then also take on the role of Release Manager for > Ruby itself. We may be willing to do this, but > Some misc thoughts: > > - Could gems ALSO cover binaries AND binary/library dependencies? RPA is working towards this. > - Could the gems RDOCs have links to some gems-aligned community > documentation site, as someone else proposed here recently? It is not clear to me what you want here. Cross-links between packages is certainly interesting for RPA, at least. Eivind. -- Hazzle free packages for Ruby? RPA is available from http://www.rubyarchive.org/