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


marcandre (Marc-Andre Lafortune) wrote:
> vo.x (Vit Ondruch) wrote:
> >> I'm was actually wondering why they are in the main repository at all...
> >
> > That would allow to keep the upstream .gemspecs without modifications.
> 
> I'm sorry, I don't understand.

You can compare the bundler.gemspec from Ruby and upstream:

https://github.com/ruby/ruby/blob/master/lib/bundler/bundler.gemspec
https://github.com/bundler/bundler/blob/master/bundler.gemspec

which are not the same. You can look at the other .gemspec files and compare them with the upstream versions.

You can also see the rbinstall.rb logic handling all this, e.g.

https://github.com/ruby/ruby/blame/master/tool/rbinstall.rb#L662
https://github.com/ruby/ruby/blob/master/tool/rbinstall.rb#L813

which is full of various exceptions and heuristics. And there are other various issues due to the strange placement of the .gemspec files and their content:

https://github.com/bundler/bundler/pull/6985

IOW it would be easier, if Ruby shipped with the upstream .gemspec files on the level where they are upstream. In the gems upstream repositories, the .gemspec files are typically in root directory and the library files in lib/ subdirectory, which would perfectly match with the Ruby directory hierarchy.

BTW there is my PR trying to use more RubyGems functionality to install the default gems replacing the custom rbinstall code:

https://github.com/ruby/ruby/pull/2545

where I mention prime.gemspec and irb.gemspec which are unnecessarily modified.

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

* Author: nahi (Hiroshi Nakamura)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* Target version: 
----------------------------------------
=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


---Files--------------------------------
5481.pdf (78.2 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>