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.9 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_PASS 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 3CCDF1F609 for ; Wed, 28 Nov 2018 17:41:21 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 09746121564; Thu, 29 Nov 2018 02:41:17 +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 C545512154F for ; Thu, 29 Nov 2018 02:41:14 +0900 (JST) Received: by filter0167p3mdw1.sendgrid.net with SMTP id filter0167p3mdw1-31131-5BFED336-73 2018-11-28 17:41:11.020258416 +0000 UTC m=+1115188.752124203 Received: from herokuapp.com (ec2-54-196-120-135.compute-1.amazonaws.com [54.196.120.135]) by ismtpd0047p1mdw1.sendgrid.net (SG) with ESMTP id UD3qE6_bQraQTTst_WCHBA for ; Wed, 28 Nov 2018 17:41:10.881 +0000 (UTC) Date: Wed, 28 Nov 2018 17:41:11 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65526 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15354 X-Redmine-Issue-Author: vo.x 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5TrNepw5Vhl5JTtRLCH9DEQuZOs3hHbYkJgQ Io6zEiL6CocZ/6c3Eb960I5kXLwPEkxme7zJt1jwi3uJdQkt/X3SQhylQqyztLG7/0BtzGtFnULMy7 3HEvowQxSa7m0jW1qEzPDiBTWCSn9w+Uth171FPLSMWHE4Bim/juXN1iLw== X-ML-Name: ruby-core X-Mail-Count: 90129 Subject: [ruby-core:90129] [Ruby trunk Bug#15354] Remove Bundler from StdLib 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="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15354 has been updated by shevegen (Robert A. Heiler). I personally do not use bundler, so I don't mind either way, but I use gems (and would love to preserve gems how I used them in the last ... 10 years or so; e. g. only using .gemspec rather than Gemfile). I understand the discussion is a lot between maintaining the rubygem-code and functionality made available through bundler. I further assume that a lot of rails users make use of bundler + Gemfile a lot; while I do not use rails myself either (it's surprising how much I don't use, but I DO use ruby just about daily), I think the net benefits outweigh the problems as described here. So I think it is not really a realistic suggestion to remove bundler, even more so after the efforts to integrate it. I may be wrong, but I think I remember indirect commented that he is committed to iron out any potential problems in regards to bundler; and among the ruby core team, Hiroshi is the one doing a lot of work to make the integration happen. I do not have enough insight knowledge to comment how bundler and gem co-operate with one another; and how it then interacts with the rest of ruby. However had, I think the ruby xmas release will be considered a stable build, so things not working there will probably not make it into the xmas release. As I myself am not affected I don't mind either way but I would hope that the bundler team would like to see bundler become an "official" part of ruby distributed by default. This would actually be a net win for those who DO use bundler. There is still a month left so I'd give them a bit more time. Having fileutils duplicated is ... strange indeed, but I do not think this is intended, so I'd just be patient for the moment. PS: We can already have multiple versions via gems, and I assume via bundler too. I don't know the bundler way (it is too complicated for me), but with gems "gem" always asks me if I want to uninstall something, and if there is more than one version, which version to remove, or whether to remove all of them. I think such functionality should be kept the same without duplicates. I assume that bundler itself may also become a bit simpler when it is a "first-class citizen" like gem, e. g. it could "ask" gem to uninstall something, and gem would know where bundler puts stuff too. Duplicates more sound like a bug; a bug that ought to be fixed, but this should not be confused with equaling it as a "removing bundler from stdlib" - that is not realistic, even if we may all agree that the quality could be improved. In the event that bundler could never be merged, I don't see the big problem either - it could stay separate too, at the least as far as I am concerned. :) Gem suffices for my needs perfectly well (I manage everything on my own though, via ruby; including compiling things from source, tracking gems etc... so I have no need for bundler since my ruby scripts do something very similar in the end. I understand that different people aren't the same and have different use cases - I think what is forgotten in the issue tracker here, or the one from a year ago, is that it is indeed these ruby users that COULD benefit the most from bundler being part of ruby by default, are, in my opinion, the biggest pro-reason for trying to merge bundler into ruby). Perhaps we could get one from the bundler team to also comment on it - it seems as if only Hiroshi comments but not the bundler core team? Do they not read the main issue tracker here? ---------------------------------------- Bug #15354: Remove Bundler from StdLib https://bugs.ruby-lang.org/issues/15354#change-75249 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.6.0dev (2018-11-26 trunk 65990) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- [This is mostly a clone of #13978 which I opened a year ago. Unfortunately, the same points I mentioned there still hold true.] I understand that given that almost every Ruby user is using Bundler, it would be convenient for quite some people to have Bundler as part of StdLib. However, seeing two copies of Molinillo, each in a different version [1], [2], similarly to fileutils [3], [4], is a sign that things are not as they should be. Therefore, please consider removal of Bundler from StdLib unless upstream demonstrates it can maintain it properly. [1]: https://github.com/ruby/ruby/blob/trunk/lib/bundler/vendor/molinillo/lib/molinillo/gem_metadata.rb#L5 [2]: https://github.com/ruby/ruby/blob/trunk/lib/rubygems/resolver/molinillo/lib/molinillo/gem_metadata.rb#L4 [3]: https://github.com/ruby/ruby/blob/trunk/lib/bundler/vendor/fileutils/lib/fileutils.rb [4]: https://github.com/ruby/ruby/blob/trunk/lib/fileutils.rb -- https://bugs.ruby-lang.org/