ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:90129] [Ruby trunk Bug#15354] Remove Bundler from StdLib
Date: Wed, 28 Nov 2018 17:41:11 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-75249.20181128174110.49170909940e478f@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15354.20181128171101@ruby-lang.org

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/

  parent reply	other threads:[~2018-11-28 17:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15354.20181128171101@ruby-lang.org>
2018-11-28 17:11 ` [ruby-core:90125] [Ruby trunk Bug#15354] Remove Bundler from StdLib v.ondruch
2018-11-28 17:13 ` [ruby-core:90128] " leamhall
2018-11-28 17:41 ` shevegen [this message]
2018-11-28 22:53 ` [ruby-core:90139] [Ruby trunk Bug#15354][Assigned] " hsbt
2018-11-29  5:51 ` [ruby-core:90152] [Ruby trunk Bug#15354] " Greg.mpls
2018-11-29  6:35 ` [ruby-core:90154] " v.ondruch
2018-11-29 23:09 ` [ruby-core:90178] " colby
2018-11-30  0:49 ` [ruby-core:90179] " Greg.mpls
2018-11-30  1:01 ` [ruby-core:90180] [Ruby trunk Bug#15354][Rejected] " hsbt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-75249.20181128174110.49170909940e478f@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).