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=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham 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 903051F5AD for ; Sat, 11 Apr 2020 19:57:23 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 3DCE3120A9C; Sun, 12 Apr 2020 04:56:58 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id AE860120A9B for ; Sun, 12 Apr 2020 04:56:55 +0900 (JST) Received: by filter0135p3las1.sendgrid.net with SMTP id filter0135p3las1-9353-5E922114-20 2020-04-11 19:57:08.192235052 +0000 UTC m=+858015.096011255 Received: from herokuapp.com (unknown) by ismtpd0006p1iad2.sendgrid.net (SG) with ESMTP id 3YuSR3i9TSaIrm6TOElBCw for ; Sat, 11 Apr 2020 19:57:08.103 +0000 (UTC) Date: Sat, 11 Apr 2020 19:57:08 +0000 (UTC) From: deivid.rodriguez@riseup.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 73596 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Misc X-Redmine-Issue-Id: 16778 X-Redmine-Issue-Author: deivid X-Redmine-Sender: deivid 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?klzXTY0v3jOvaMSihdVenmzxCeXPrK4t1AV7GwiE8Tih=2FXLgkLlmXVW3fzVh0t?= =?us-ascii?Q?I1rApFfoW04XXK1fgsApNE55BQeCZt=2FDLwqShG2?= =?us-ascii?Q?hoJGHeb+l=2F0Rp5ktZmoAEJRPWi0eznYCgn82xl4?= =?us-ascii?Q?o1kq6KT2rbNGK5uD2k5ac=2F9=2Fl+tbc3R=2FkoAJLCF?= =?us-ascii?Q?9Z8+75LkgMaI55THXscSB34UK32gLz8sAlw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 97835 Subject: [ruby-core:97835] [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 deivid (David Rodr=EDguez). Yeah! You're right about those other reasons. Specially for security issues= in standard libraries, gemification is great. I believe those benefits rem= ain with my proposal though. I didn't mention any drawbacks because I couldn't think of any. Some stuff = came to my mind, but in the end, I'm not sure they are really drawbacks. Fo= r example: * ruby-core developers will no longer be able to add changes directly to de= fault libraries in the ruby-core repo. That's true, but this seems like an = improvement to me. In the previous situation, they would also need to go to= the upstream repo and propose those same changes. And if they forget to do= that, merging the upstream repo back into ruby-core would revert their cha= nges and make the original issue reappear. This has happened in the recent = past, and normally due to issues related to the different structure of the = repositories. All these issues would be gone with my proposal. * There will be some extra download of code from the network when some make= targets are first run after cloning the repo. Well, this is true, but ther= e will be less code downloaded when ruby is cloned because all the default = libraries will no longer be vendored. So I don't really think this is a dra= wback either. Hope this made my proposal a bit more clear. So, to answer the question of "what would actually be changed as a conseque= nce of this"? * User facing changes: none. I would expect the result of `./configure && m= ake && make install` to be exactly the same. This is a proposal to change o= nly how default gems are managed _internally_. * Developer facing changes: minimal, and should be aimed to make the ruby-c= ore developer experience better. The idea is that: * There will be no more need of default gem syncronization bringing code = from upstream into ruby-core's source control. So, less work. * There will be no more need to test default gems inside ruby-core repo. = So lighter local tests, lighter CI. * No more code duplication between ruby-core and upstrem repos. So, less = code duplication, less confusion for contributors. * Any other ruby-core developer local workflows other than these things s= hould remain unchanged. ---------------------------------------- Misc #16778: Should we stop vendoring default gems code? https://bugs.ruby-lang.org/issues/16778#change-85057 * 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: