M
Mauricio Fernández
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 ;-) 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
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 ;-) 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