Ruby » Ruby master

As far as I know, bundler is planned to be merged to rubygems. If shipping bundler as a gem is ephemeral, it looks less significant to me whether bundler should be a bundled gem or a default one.

In fact, rubygems already includes some special code for bundler, e.g., bundler_version_finder.rb. I think that it is going to be unreasonable to separate bundler as a gem.

Just my two cents,

Yes, I was going to comment exactly along the same lines mame presents.

Also, moving bundler to a default gem would still keep the same problem in https://bugs.ruby-lang.org/issues/15610, but only for the rubygems code. Although to be honest, having duplicated versions of the rubygems code in rubylibdir and site_ruby has not yet led to real world issues that I know of. But still, moving both to site_ruby feels cleaner and safer to me.

As far as I know, bundler is planned to be merged to rubygems.

What would that mean exactly? (that's a question for Bundler/RubyGems devs)
Will both repositories become one and the code be reused for both parts? That's what I would consider "merged".
Otherwise, it looks like two different softwares with different versions. Currently it doesn't look merged at all to me.

If shipping bundler as a gem is ephemeral, it looks less significant to me whether bundler should be a bundled gem or a default one.

Not sure how ephemeral, but right now bundler is a default gem in the 2.6 releases, and as argued above I think it's an actual issue for it to be a default gem.

Also, moving bundler to a default gem would still keep the same problem in https://bugs.ruby-lang.org/issues/15610, but only for the rubygems code. Although to be honest, having duplicated versions of the rubygems code in rubylibdir and site_ruby has not yet led to real world issues that I know of. But still, moving both to site_ruby feels cleaner and safer to me.

RubyGems has been in stdlib since 1.9, so there is some history there, and RubyGems itself cannot be a gem of course.
But I agree, it would be more consistent to always have RubyGems be installed the same directory.
I wonder what should happen when upgrading RubyGems fails while copying files though, maybe having a safe copy somewhere would be a good way to deal with that.

I think it would be better if every part of stdlib that can be upgraded could be cleanly removed and handled like a real gem, which seems very complicated for stdlibs directly under lib/.
This also applies for other default gems part of the stdlib.

Also, moving bundler to a default gem would still keep the same problem...

When I said "default gem" before I meant "bundled gem", but I think you understood me... :)

¿What would that mean exactly? (that's a question for Bundler/RubyGems devs)
Will both repositories become one and the code be reused for both parts? That's what I would consider "merged".
Otherwise, it looks like two different softwares with different versions. Currently it doesn't look merged at all to me.

Yeah, that's what it means. But it's currently only a long term goal.

RubyGems has been in stdlib since 1.9, so there is some history there, and RubyGems itself cannot be a gem of course.
But I agree, it would be more consistent to always have RubyGems be installed the same directory.
I wonder what should happen when upgrading RubyGems fails while copying files though, maybe having a safe copy somewhere would be a good way to deal with that.

Right, I guess that's precisely why rubygems is currently shipped in rubylibdir, so that the default installation is never changed?