From: Hiroshi Nakamura Date: 2011-10-25T06:49:34+09:00 Subject: [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 (()) == 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