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

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


Hi, I'd like to question once more some parts of the proposal in wiki [1].

* After installing updated stdlib gems, those should be treated as regular gems.

The only viable solution is proposal 1. It seems that there was some work started to implement 2, but that is really wrong approach. What would be the purpose of --disable-gems then? You disable gems but they will be loaded to load some default gems? That doesn't make sense to me.

Moreover, if you have reason to use --disable-gems option, you will be probably able to use -I to setup your load paths to load the gems manually.

* Introduce a new mechanism: controlling supported ruby version

There is already mechanism in RubyGems, i.e. you can specify version of Ruby which is supported by the gem, not sure why there should be anything more. Since the StdLib gems would go into independent directory and they are uninstallable, there can't be installed any "unexpected version of stdlib gems". If this should solve that there might be installed to new gem, then I guess Ruby developers are already used to this. So not sure what would this improve.

* Newly created stdlib gems version scheme: ruby's version + '.n'(dot plus a number)

Why WEBrick should have this kind of versioning? What if there was no change in WEBrick in between Ruby 2.0 and, 2.1? Why the version should be changed? Every gem should have independent versioning, as maintainer decides. Bind the gems versioning to Ruby versions makes no sense and it is not beneficial.

* Uninstalling 'default gems' should be blocked to avoid confusion. RubyGems bundled with 1.9.3 allows users to uninstall 'default gems' now.

Yes, since currently, the default gems are mixed with regular gems, they are uninstallable. This would be non issue ff they are in different path.

* And one more note from Fedora's Ruby maintainer point of view

It has to be possible to unbundle the default gems out of Ruby and replace them with newer versions if needed. This is similar requirement as Lucas Nussbaum pointed our earlier in this discussion. There are also different reasons, such as for example, Ruby is dependency of VIM in Fedora and VIM users really don't want to install RDoc, Minitest, Rake etc, just because they want to use VIM.

Please note that we are already doing so in Fedora and there are no issues, except #6124

[1] https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem
[2] https://github.com/rubygems/rubygems/pull/377#issuecomment-9735417
----------------------------------------
Feature #5481: Gemifying Ruby standard library
https://bugs.ruby-lang.org/issues/5481#change-32009

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/