From: Its Me Date: 2004-10-28T05:49:02+09:00 Subject: Re: Gems as key? Re: The real Ruby vs. Python. "Eivind Eklund" wrote in message > > - including compatible versions and dependencies > The latter is a property of package repository administration, not of RubyGems. I dont understand. Gem does transitive dependencies while being aware of versions. Any package manager and installer should do this. > > 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. I am sure there are things you need beyond core Gems. But there is such a core of rubygems (at least notionally; I don't know the architecture) that directly overlaps a core of RPA: installing a package, knowing dependencies, and installing dependees. module Gem; require_gem 'Core'... end module RPS; require_gem 'Core' ... end There will doubtless be many repositories of gems, perhaps just one authoritative repository of RPA packages. I believe the RPA repository should be a (very) special case of a Gem repository. > 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 That's great. But when RPA maintains a package -- a very non-trivial and important undertaking -- if that involves some changes in the packaging or the contents within the packaging, surely there is a NEW version of something being created. Once that new version is published, I think it is a bona-fide Gem. If you think of packages having a status that includes at least { published, editable ...}, then a published package has an immutable version#, name, and content, and any package it depends on must also be published. Perhaps newer versions of a package could be related to the original as "backward-compatible version" or "incompatible variant", and Gem could make use of this distinction. Otoh, CVS head represents an "Editable" package status. > 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 These are great, and 100% valid. It's just that there is a core that seems identical, Imho.