[ruby-core:40317] [ruby-trunk - Feature #5481] Gemifying Ruby standard library

Issue #5481 has been updated by Hiroshi Nakamura.


=begin
== Implementation

=== Install stdlibs as 'default gems'

 * Newly created stdlib gems version scheme: ruby's version + '.n'(dot plus a number)
   * ex. WEBrick 'default gem': 2.0.0.0, 2.0.0.1, ...
   * Gems which supports multiple ruby versions (ex. rake, rdoc, etc.) keeps their version.
 * Controlling supported ruby version by specifying "platform". In RubyGems, currently the ruby platform only allows a major and minor version (1.8 or 1.9)
 * Uninstalling 'default gems' should be blocked to avoid confusion. RubyGems bundled with 1.9.3 allows users to uninstall 'default gems' now.
     % gem uninstall webrick -v 2.0.0.0 #=> should raise an error.
 * An updated version of an stdlib gem should be treated as regular gems. With the current 'default gems' implementation, a newer gem will not automatically override the default gem with 'require':
     % ruby -rwebrick -e 'p WEBrick::VERSION' #=> 2.0.0.0
     % gem update webrick
     Updating installed gems
     Updating webrick
     Fetching: webrick-2.0.1.5.gem (100%)
     Successfully installed webrick-2.0.1.5
     Gems updated: webrick
     Installing ri documentation for webrick-2.0.1.5...
     Installing RDoc documentation for webrick-2.0.1.5...
     % ruby -rwebrick -e 'p WEBrick::VERSION'                    #=> 2.0.0.0 << should be 2.0.1.5
 * Make autoload for stdlib gems work as long as autoload feature exists in 2.0.
     % ruby -e 'autoload :JSON, "json"; p JSON' #=> "JSON"

For existing 'default gems' see tool/rbinstall.rb. It installs stdlibs as 'default gems'.
 * It scans {lib,ext}/**/*.gemspec and installs it as a spec-only gems via rubygems.
 * Then installs gemdir/bin/* as executables (it would be better to use rubygems instead.)
 * It also reads defs/default_gems, but those are obsolete.

=== Register 'default gems' on RubyGems.org

 * Improve 'default gems' for creating gem from stdlib file/directory layout.
 * stdlib gems maintainer registers the updated gems on RubyGems.org.
   * Maintainer must have an account at RubyGems.org

== ToDo

 * After installing updated stdlib gems, those should be treated as regular gems. How?
   (1) Installing 'default gems' as a real gem to /usr/local/lib/ruby/default_gems/, not to /usr/local/lib/ruby/site_ruby/
        * advantage: simple implementation
        * drawback: stdlib gems cannot be loaded with --disable-gems.
   (2) Implement it as a new feature of RubyGems.
        * advantage: stdlib can be loaded without --disable-gems
        * drawback: may penalize ruby startup time
        * drawback: may be complex to implement

       The RubyGems team tried to implement a feature similar to this for ruby 1.9.1 and ruby 1.9.2, but it did not work out very well...
   (3) ?
 * To avoid installing an incompatible version of stdlib gems, update RubyGems to allow three digits (1.8/1.9 -> 1.9.X) on a "ruby" platform in the gem spec.
 * Uninstalling 'default gems' should be blocked. Set default path to /usr/local/lib/ruby/default_gems/
 * Improve 'default gems' for creating gem from stdlib file/directory layout.
 * Decide which stdlibs should be gemified. Let's ask maintainers.  We would need to find maintainers of some stdlibs if needed.
 * Decide tagging/branching policy for stdlib gems.  Up to the release manager?
 * Find a way to allow autoloading stdlib gems.
   * It's because autoload does not respect require overwriting now. When we install 'default gems' as a real gem, it needs some care to work.

== What stdlibs should be gemified?

=== Principle

 * The lib must have a maintainer.
 * The lib should be highly independent from ruby's code base.
   * Feature dependencies are OK since RubyGems can resolve them. ex. net/http -> openssl

=== Stdlib status

 * lib/benchmark
 * lib/cgi
 * lib/csv
 * lib/drb
 * lib/erb
 * lib/irb
 * lib/logger: NaHi will maintain this as a 'default gem'
 * lib/optparse
 * lib/pstore
 * lib/racc
 * lib/rexml
 * lib/rinda
 * lib/rss
 * lib/webrick: NaHi will maintain this as a 'default gem'
 * lib/xmlrpc
 * lib/yaml
 * lib/rake
 * lib/net: Do we split this to core, ftp, http (and https), mail (imap, pop and smtp) and telnet?
 * ext/curses
 * ext/date
 * ext/digest
 * ext/iconv: Deprecated. New products and libraries should not use this
 * ext/openssl
 * ext/sych

Already a 'default gem':

 * lib/minitest
 * lib/rake
 * lib/rdoc
 * lib/rubygems
 * ext/bigdecimal: Not yet registered at RubyGems.org (Mrkn will register that to RubyGems.org after RubyConf 2011).
 * ext/io-console: Not yet registered at RubyGems.org
 * ext/json
 * ext/psych

== Call for discussion

 * Topics at ToDo above.
 * What stdlibs should be gemified?

Please post comments to this ticket. I'll update the Wiki page at https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem as a summary.
=end
----------------------------------------
Feature #5481: Gemifying Ruby standard library
http://redmine.ruby-lang.org/issues/5481

Author: Hiroshi Nakamura
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 2.0


=begin

Up-to-date summary of this proposal is at ((<URL:https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem>))

== Motivation

 * ruby's release cycle is slow for some standard libraries;
   * ex. security fix for WEBrick, xmlrpc and Zlib.
   * ex. API iteration for net/http, OpenSSL, json, psych, RDoc, minitest and rake.
 * There's already the feature called 'default gems' in ruby and some stdlibs are already using it:
   * rake, rdoc, minitest, json, io-console, bigdecimal
   * And some gems are already doing out-of-band releases.
 * When releasing we should give independence equally to all stdlibs, but in a consistent and controllable way.

== Proposal

 * Allow out-of-band stdlib releases.
   * We are not proposing changes to ruby's release management, the release manager would decide when they release ruby and stdlib.
 * Allow more stdlibs to be installed as a 'default gem'
 * Register these gems on RubyGems.org
   * Introduce a new mechanism: controlling supported ruby version so that we can avoid installing unexpected version of stdlib gems.
     For example, a WEBrick gem for ruby 2.0.1 (released from ruby_2_0_1 branch) should not be installed for ruby 2.0.0 (released from ruby_2_0_0 branch) unless we know it works for both 2.0.0 and 2.0.1.

Note:

 * Moving stdlibs repository location is not a target of this proposal. The implementation details of stdlib gems should hide this from ruby committers.
 * ruby_1_9_3 is not a target of this proposal. The change should be introduced from 2.0.0 release.


...Some more details of the proposal and discussion topics are going to follow as comments.
=end



-- 
http://redmine.ruby-lang.org