A concrete solution to RubyGems' repackageability problems

We’ve gone through lengthy discussions and come so far:

http://www.rubygarden.org/ruby?RubyGemsToDoList

I have realized that several of the most important items in that list
overlap with the goals set by Christian Neukirchen for Package.rb
[1, http://tinyurl.com/d2lck]. Package.rb [2] has been developed with
repackagers in mind; it is therefore not surprising that it addresses
the RubyGems issues they reported.

It only makes so much sense for RubyGems to take advantage of the
effort invested in Package.rb. It is undergoing quick development and
by now offers the basic functionality needed to complement RubyGems.
Also, several of the issues listed in the above TODO transcend RubyGems
itself; since Package.rb can also be used without depending on RubyGems,
developers can rely on it without running into repackageability
troubles. In addition to that, Package.rb also helps prevent the
problems with RubyGems packages used as source archives instead of
distribution formats, as explained in [ruby-core:06251] and
summarized by Jim Weirich in [ruby-core:06255].

The inclusion of Package.rb in RubyGems would benefit:

Developers:

  • specification format carefully designed for maximum ease of use:
    in most cases, a ~7-line install.rb will be able to
    • install the software locally
    • pack the sources for a “pristine” tarball release
    • generate the RubyGems package
  • Package.rb simplifies the RubyGems packaging process by following
    the standards embodied in setup.rb (and nowadays known as “convention
    over configuration”).
  • the implicit gem lint functionality helps them avoid common errors
  • their software can be installed with and without RubyGems, without
    additional effort on their behalf
  • upstream releases made with Package.rb become automagically RubyGems
    releases.
  • extension building will be simplified (in progress)

End users:

  • can still use RubyGems as they have before — all current .gem packages
    work, existent gemspecs still work.
  • can choose alternative install methods, including native port/package managers
  • can choose whether to place a library in sitelibdir

Repackagers:

  • unified repackager-friendly format for all sw. written in Ruby
  • ability to automate partially the packaging process thanks to a predictable
    structure and consistent standards

RubyGems developers

  • interaction with repackagers done through Package.rb, which has been
    designed and implemented based on the feedback from experienced repackagers
  • less work :wink: much of the TODO

I am now helping Christian develop Package. It won’t take long before the
"RubyGems glue" code becomes usable and Package can solve many of RubyGems’
long-lasting issues.

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/144579

[2] I think Christian is still looking for a better name; suggestions
will be appreciated :slight_smile:

···


Mauricio Fernandez

Not having tracked all the discussion, are you proposing something that
replaces or offers an alternative to gems (not a good idea at this stage in
the game, imo), or something that addresses some gem issues in a way that
promotes more gems (a good idea, imo)?

···

"Mauricio Fernández" <mfp@acm.org> wrote

We've gone through lengthy discussions and come so far:

   http://www.rubygarden.org/ruby?RubyGemsToDoList

I have realized that several of the most important items in that list
overlap with the goals set by Christian Neukirchen for Package.rb
[1, http://tinyurl.com/d2lck\]. Package.rb [2] has been developed with
repackagers in mind; it is therefore not surprising that it addresses
the RubyGems issues they reported.

Rather the latter:
something that complements RubyGems, addressing several of the issues listed in
RubyGemsToDoList, and which would make it easier to create RubyGems packages.
It would be integrated in RubyGems, but could be used separately too.

···

On Fri, Oct 14, 2005 at 01:16:54PM +0900, itsme213 wrote:

> We've gone through lengthy discussions and come so far:
>
> http://www.rubygarden.org/ruby?RubyGemsToDoList
>
> I have realized that several of the most important items in that list
> overlap with the goals set by Christian Neukirchen for Package.rb
> [1, http://tinyurl.com/d2lck\]. Package.rb [2] has been developed with
> repackagers in mind; it is therefore not surprising that it addresses
> the RubyGems issues they reported.

Not having tracked all the discussion, are you proposing something that
replaces or offers an alternative to gems (not a good idea at this stage in
the game, imo), or something that addresses some gem issues in a way that
promotes more gems (a good idea, imo)?

--
Mauricio Fernandez