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

Issue #5481 has been updated by vo.x (Vit Ondruch).


=begin
Hi,

I played around a bit an put together a few patches. You can find it here: https://github.com/voxik/ruby/commits/gemified-stdlib . I took Rake as an example.

In a nutshell:

(1) I created the gems/ subdirectory in Ruby repository.
(2) I moved the Rake bits into gems/rake/
(3) I added .gemspec for Rake
(4) I modified rbinstall.rb to install each gem found in gems subdirectory into standard StdLib gem location
(5) I modified RubyGems to look into StdLib gem location for gems.
    
What is currently missing:

(1) The test suite is not passing currently, but I think that the Rake's test suite should be moved into the gems/rake/ subdirectory as well and there should be some mechanism, how to execute test suites of gems.
(2) If there would be some binary gem, its binary extension is not build ATM. However, I would say that similar approach used to build current exts could be used.

This approach has significant advantages IMO:

(1) Rake gem currently reflect the upstream repository and as soon as the tests are moved into the gems/rake/ subfolder, it will be almost exact match. It could be easily replaced by something like svn:externals or git submodule. This would greatly improve the maintainability of the code and reduced the possibility of forking.
(2) This would help alternative Ruby implementations to ship their additional libraries in consistent manner.
(3) Gems could be easily replaced by downstream distributions by different versions, if needed.

Any comments? Would this approach be acceptable? Should I try to spend more time polishing the test suite and binary extension's build?
=end

----------------------------------------
Feature #5481: Gemifying Ruby standard library
https://bugs.ruby-lang.org/issues/5481#change-34043

Author: nahi (Hiroshi Nakamura)
Status: Assigned
Priority: Normal
Assignee: nahi (Hiroshi Nakamura)
Category: lib
Target version: next minor


=begin

Up-to-date summary of this proposal is at ((<URL:https://bugs.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://bugs.ruby-lang.org/