"Eivind Eklund" <eeklund@gmail.com> 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.
I told earlier you its up to us, not end users.