[ruby-core:98339] [Ruby master Misc#16778] Should we stop vendoring default gems code?
From:
hsbt@...
Date:
2020-05-14 04:36:58 UTC
List:
ruby-core #98339
Issue #16778 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Feedback We still wait for the PoC of this issue. ---------------------------------------- Misc #16778: Should we stop vendoring default gems code? https://bugs.ruby-lang.org/issues/16778#change-85606 * Author: deivid (David Rodr=EDguez) * Status: Feedback * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Currently ruby-core vendors all the code in default gems, and runs the test= s for each of them. Also, ruby-core continuously updates the vendored code of default gems to s= ync with the upstream repos. That's overhead work, not only from syncronizi= ng the code itself, but it also requires perfect syncronization of releases= to avoid including versions of default gems that are different from releas= ed versions. Also, this causes confusion for contributors because the code lives "duplic= ated" in two different places. Some times contributors will open a PR in th= e ruby-core repo, only to find out that they need to go to the upstream rep= o and contribute it in there. And this rule is not even always followed and= sometimes ruby-core contributors apply patches to the vendored code direct= ly (many times to fix test-only issues inherent to the different structure = of the core repository). These patches then need to be contributed back to = the upstream repo. I believe that all of that kind of defeats the point of "gemification" of t= he standard library. Once some ruby code its gemified, it should be the new upstream's responsab= ility to make sure the code works and it's properly tested, and ruby-core s= hould be free'd from that responsability. Maybe ruby-core could do something along the following lines: * Remove all the vendored code from default gems. * When this code is needed for internal tests, manage it as a development d= ependency, clone it as necessary on non source controlled locations, and us= e it from there. * Maybe a file similar to `gems/bundled_gems` can be added for default gems= indicating their versions and upstream repos, to ease things. * Upon `make install`, clone the proper version of each default library and= get it installed in the default $LOAD_PATH. * Maybe add some bare high level CI checks to ensure that all default libra= ries can be properly required after `make install`, and that their executab= les (if they include any) can also be run. This should bring several benefits to the development process: * No more duplicated code. * No more syncronization from upstream to ruby-core. * No more syncronization from ruby-core to upstream. * No more confusion around the canonical place to contribute. * No more complexities derived from the different organization of the code = depending on whether it lives in ruby-core or outside. = I believe jruby already does something like this so it'd be interesting to = get some input from them. If this is a direction the ruby-core team would like to take, I'm happy to = help @hsbt with small steps towards slowly approaching to this high level g= oal. -- = https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=3Dunsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>