From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 1ED2A1F5AD for ; Sat, 11 Apr 2020 19:02:52 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CA223120BCC; Sun, 12 Apr 2020 04:02:28 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id D130C120BC7 for ; Sun, 12 Apr 2020 04:02:26 +0900 (JST) Received: by filter0081p3las1.sendgrid.net with SMTP id filter0081p3las1-23682-5E92144F-16B 2020-04-11 19:02:39.842655172 +0000 UTC m=+855101.032419178 Received: from herokuapp.com (unknown) by ismtpd0017p1iad2.sendgrid.net (SG) with ESMTP id Rlrxh_RlTTWQKlibxGmtNQ for ; Sat, 11 Apr 2020 19:02:39.688 +0000 (UTC) Date: Sat, 11 Apr 2020 19:02:39 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 73595 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Misc X-Redmine-Issue-Id: 16778 X-Redmine-Issue-Author: deivid X-Redmine-Sender: shevegen X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0yVG9CbVjz6ciCM9si6I=2F?= =?us-ascii?Q?AEhSxiin4cn4FNaHq7yMdBgzsNgQOVcX9SP9iiJ?= =?us-ascii?Q?AKk3m0c+4bW=2Ffu055chWVwYJDuCFsJeX8qJ84mx?= =?us-ascii?Q?EYyAT9aqpCHGuAHyUrTv4gjMGuco4n1LAJH=2Fk1F?= =?us-ascii?Q?7WBnP4sbgB3tsWQ0Qfc84hix7HuD2BABSFQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 97834 Subject: [ruby-core:97834] [Ruby master Misc#16778] Should we stop vendoring default gems code? X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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: