[ruby-core:98099] [Ruby master Feature#5481] Gemifying Ruby standard library

Issue #5481 has been updated by marcandre (Marc-Andre Lafortune).


While `tool/sync_default_gems` can be useful to overwrite files, in some circumstances it won't help (e.g. different changes in both directories). I also wanted to move commits across repositories and not loose history.
I found a solution that might benefit others, using the power of `git`.

My setup is same as for `tool/sync_default_gems`, i.e. the main ruby repo in `~/ruby/something` and `~/ruby/matrix` is the `matrix` library repository; change the paths below accordingly.

First time setup in the main repo:
```
git remote add lib_matrix ~/ruby/matrix/.git
git config remote.lib_matrix.tagopt --no-tags
```
Also do the same in the library repo if you need to bring commits the other way (i.e. from the main repo to the library)

This can seem quite strange because we are adding a "remote" that is a local git repository and that also has a completely unrelated history! But this makes it possible for `git` to have access to both histories at the same time.

To bring a commit from the library repository:
```
git fetch lib_matrix
git format-patch --stdout -1 <commit hash> | git am -3
```

This seems to automagically recognize the different paths from one repo to the other (e.g. `lib/matrix/matrix.gemspec` vs `matrix.gemspec`) and apply the patch correctly. `git` is awesome ♥️

If the commit in question changes more than just the library, you must limit the produced patch to just the desired files by specifying them. For example:

```
git format-patch --stdout -1 9f1fb0a17f lib/matrix* test/matrix | git am -3
```

HTH

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

* Author: nahi (Hiroshi Nakamura)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
----------------------------------------
=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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>