[ruby-core:97834] [Ruby master Misc#16778] Should we stop vendoring default gems code?

Issue #16778 has been updated by shevegen (Robert A. Heiler).


> I believe that all of that kind of defeats the point of "gemification" of
> the standard library.

If I remember correctly then this was not the only reason made in favour of
gemifying core. One, for example, was that it becomes easier to change =

existing code, correct bugs etc... - this may help distributions such as,
say, debian, when there is some known bug already fixed, in a gem release,
and it can be quickly updated, without having to wait for e. g. x-mas =

release or pull out some patch manually. So that was one additional reason
for gemification.

I think there are more reasons for gemification.

Anyway, I believe your proposal/question is mostly related to Hiroshi, so =

we should probably wait until he has time to comment. :)

There is something I seem to be missing, or perhaps not fully understanding
yet, and that is: what will actually be changed as a consequence of this?

You mention potential benefits but not any (possible) drawbacks of the
proposed change (if there are drawbacks). For example, Greg mentioned
"We also need to consider working locally.", so perhaps this affects the
workflow of other people.

----------------------------------------
Misc #16778: Should we stop vendoring default gems code?
https://bugs.ruby-lang.org/issues/16778#change-85056

* Author: deivid (David Rodr=EDguez)
* Status: Open
* Priority: Normal
----------------------------------------
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:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>