I’ve been squinting at the “global cache for all bundler instances” issue[1] and I’m trying to figure out if it’s a minefield of hidden complication or if it’s actually relatively straight forward.
It’s interesting as a target because it pays off more the longer it has been implemented as it only would be shared from versions going forward.
[1] https://github.com/ruby/rubygems/issues/7249
In Can Bundler be as fast as uv?ruby
rubygems
Ruby2010–2026
ruby / rubygems
rubygems
Library packaging and distribution for Ruby.
40Distinct people
44Mentions
0Explicit recommenders
4KGitHub stars
What to know before exploring
What it is
Library packaging and distribution for Ruby.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year44 dated mentions
Observed mentions: 2010-06-10 17:28:06 UTC to 2026-01-01 23:00:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
RubyGems
RubyGems is a package management framework for Ruby.
A package (also known as a library) contains a set of functionality that can be invoked by a Ruby program, such as reading and parsing an XML file.
We call these packages "gems" and RubyGems is a tool to install, create, manage and load these packages in your Ruby environment.
RubyGems is also a client for RubyGems.org, a public repository of Gems that allows you to publish a Gem
that can be shared and used by other developers. See our guide on publishing a Gem at guides.rubygems.org
Getting Started
Installing and managing a Gem is done through the gem command. To install a Gem such as Faraday:
gem install faraday
RubyGems will download the Faraday Gem from RubyGems.org and install it into your Ruby environment.
Finally, inside your Ruby program, load the Faraday gem and start hacking:
require 'faraday'
response = Faraday.get('https://rubygems.org')
# do something with `response`...
For more information about how to use RubyGems, see our RubyGems basics guide at guides.rubygems.org
Bundler
Bundler makes sure Ruby applications run the same code on every machine. It is developed in this repository and ships with Ruby.
It does this by managing the gems that the application depends on. Given a list of gems, it can automatically download and install those gems, as well as any other gems needed by the gems that are listed. Before installing gems, it checks the versions of every gem to make sure that they are compatible, and can all be loaded at the same time. After the gems have been installed, Bundler can help you update some or all of them when new versions become available. Finally, it records the exact versions that have been installed, so that others can install the exact same gems.
For example, these commands will allow you to use Bundler to manage the rspec gem for your application:
bundle init
bundle add rspec
bundle install
bundle exec rspec
For more information about how to use Bundler, see the guides at guides.rubygems.org
Requirements
RubyGems supports Ruby 3.0 or later.
Installation
RubyGems is already installed in your Ruby environment, you can check the version you have installed by running gem --version in your terminal emulator.
In some cases Ruby & RubyGems may be provided as OS packages. This is not a
recommended way to use Ruby & RubyGems. It's better to use a Ruby Version
Manager, such as rbenv or
chruby. If you still want to use the
version provided by your OS package manager, please also use your OS package
manager to upgrade rubygems, and disregard any other installation instructions
given below.
If you would like to manually install RubyGems:
Download from https://rubygems.org/pages/download, unpack, and cd into RubyGems' src
OR clone this repository and cd into the repository
Install RubyGems by running:
$ ruby setup.rb
For more details and other options, see:
$ ruby setup.rb --help
Upgrading RubyGems
To upgrade to the latest RubyGems, run:
$ gem update --system
See UPGRADING for more details and alternative instructions.
Release policy
RubyGems and Bundler share a version number and are released together.
The release policy is somewhat similar to the release policy of Ruby itself:
Frequent patch releases (every 2-4 weeks) including bug fixes, minor
enhancements, small features, or even medium sized features declared as
experimental for battle testing.
Yearly minor releases including bigger features, and minor breaking changes
(affecting only edge cases and a very small set of users).
Occasional major releases (replacing yearly minors) including major breaking
changes.
Documentation
RubyGems uses rdoc for documentation. A compiled set of the docs
can be viewed online at docs.ruby-lang.org.
RubyGems also provides a comprehensive set of guides which covers numerous topics such as
creating a new gem, security practices and other resources at https://guides.rubygems.org
Getting Help
Filing Tickets
Got a bug and you're not sure? You're sure you have a bug, but don't know
what to do next? In any case, let us know about it! The best place
for letting the RubyGems team know about bugs or problems you're having is
on the RubyGems issues page at GitHub.
Bundler Compatibility
See https://guides.rubygems.org/bundler-compatibility/ for known issues.
Supporting
RubyGems is a community project. Please consider sponsoring individual contributors for their great OSS
work.
In addition, Ruby Central administers grant-funded work for improvements to ruby/rubygems, as well as running
RubyGems.org (the service). You can support Ruby Central by attending or sponsoring
a RubyConf, or by joining as a supporting member.
Contributing
If you'd like to contribute to RubyGems, that's awesome, and we <3 you. Check out our guide to contributing for more information.
Code of Conduct
Everyone interacting in the RubyGems project’s codebases, issue trackers, chat rooms, and mailing lists is expected to follow the contributor code of conduct.
Read the full README on GitHubWhat Hacker News says
44 sourcesYup! It was deprecated on `rubygems` 3.0 and removed on `rubygems` 3.2
https://github.com/ruby/rubygems/blob/v3.1.6/lib/ubygems.rb
https://github.com/ruby/rubygems/commit/8933115bff09402f6baa...
https://github.com/ruby/rubygems/commit/7ac54d5bb3411233b405...
In Ruby already solved my problem> Nitpicking your nitpick
That's not a nitpick, that's paraphrasing ;)
> It used to not be part of the standard library, but it has been since Ruby 1.9, released in 2007.
That's the mention of 1.8 I made, but it's a bit more complex: it still can be excluded, in two ways:
- at build time via `configure` (and then it's not even there)
- at run time via `--disable-gems`
The interaction between rubygems and ruby core is surprisingly small.
> Rubygems is a default gem
It is not! See `lib/ruby/gems/3.3.0/specifications/default` in any Ruby install, or in source the absence of _any_ gemspec for `rubygems` while there is for bundler[0].
Instead it's, as you mentioned, a default library.
The very principle of gems is that you can have multiple versions of a gem separately installed (to the point of allowing only one to be visible at any one time,
Read the rest
activated by `rubygems`-provided `Kernel.gem`). The implementation of that is done by `rubygems` itself so if it were a gem, one would not be able to activate `rubygems` without `rubygems` itself...
This is also why it can be special-case upgraded only via the very special `gem update --system`, which downloads a "gem" named `rubygems-update` (not `rubygems`); scare quotes because it's using the gem format and infrastructure mostly as a delivery mechanism, not by being an _actual_ gem[1] in the traditional sense (well it is a gem, but a gem of an updater, not of `rubygems` itself).
When updated, the new copy of rubygems is installed in `site_ruby`, because the load path is the only mechanism available to define location priority (`ruby --disable-gems -e 'p $LOAD_PATH'`).
Fun fact: the only thing that "prevents" a file present it `${PREFIX}/lib/ruby/3.4.0/rubygems` to not be `load`ed or `require`d is merely that new code in `${PREFIX}/lib/ruby/site_ruby/3.4.0` shall not make reference to it, but it's all perfectly visible otherwise.
docker run --rm -it ruby:3.4 /bin/bash
gem update --system
ls -ld /usr/local/lib/ruby/3.4.0/rubygems /usr/local/lib/ruby/site_ruby/3.4.0/rubygems
echo 'p __dir__' > /usr/local/lib/ruby/3.4.0/rubygems/foo.rb
ruby -e 'p $LOAD_PATH; require "rubygems/foo"'
[0]: https://github.com/ruby/ruby/blob/v3_4_7/lib/bundler/bundler...
[1]: https://github.com/ruby/rubygems/blob/v3.7.2/hide_lib_for_up...
> it’s built into Ruby!
Nitpick: technically `Gem::Version` is part of `rubygems`, and while `rubygems` is (typically) packaged with Ruby, it's actually entirely optional, so much so that `rubygems` actually monkeypatches† Ruby core's `Kernel` (notably `require`) to inject gem functionality.
MRuby has none of it, and CRuby has a `--disable-rubygems` configure flag.
Back in 1.8 days, you even had to manually require `rubygems`!
† https://github.com/ruby/rubygems/tree/4e4d2b32353c8ded870c14...
In Ruby already solved my problemRubygems has 216 open issues right now.[0] Do you think some of them should be addressed? Without maintenance, and any PR's getting merged, they won't.
[0] https://github.com/rubygems/rubygems/issues
In Gem.coopThere are two different things, GitHub access, and gem ownership (permission to publish packages).
Based on previous posts, they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement.
However on the package publishing side, you can see that on Sept 20 3 people had access [0], hsbt, deivid and colby.
If you compare to aug 24, there was also andre, sebgiddins and rubymorillo (no idea who that is).
So that leads me to believe they had the intention to keep him, even more so because he was still contracting with them. AFAICT the intent was to remove accesses to former employees who left to start their own consultancy.
So to me, that post from RC checks out, and I think they were very well aware of who was contributing what.
[0] https://web.archive.org/we
Read the rest
b/20250920140646/https://rubygems....
[1] https://web.archive.org/web/20250824033341/https://rubygems....
Edit: answering myself on who rubymorillo was, it's someone who didn't commit in that gem since 2018: https://github.com/rubygems/rubygems/commits?author=rubymori...
So yeah, permission management at Ruby Central did indeed seem to have been a huge mess. Not excusing the extremely poor rollout, but some cleanup was definitely overdue...
I did a double-take when I read that as well. I went and checked the license under rubygems, and sure enough, it's standard MIT with no warranties.
https://github.com/rubygems/rubygems/blob/master/LICENSE.txt
In Our stewardship: Where we are, what's changing and how we'll engageI'm sorry but the article seems pretty biased, and doesn't really give any argument for why what happened would be in any way justified. Author keeps adding their own interpretation to Github comments and events, which — just by looking at the contents — are needlessly negative. For example [1] where commit message states
> We've been continuing to backport bugfixs to the 1.7.x series just for Heroku, but unless Heroku joins Ruby Together I don't have enough time available to make sure that continues to happen.
but OP claims it
> was interpreted as leveraging his control over Bundler as a pay-to-play scheme
I'm sorry but not supporting outdated versions of an open-source tool for a business is perfectly reasonable.
Similarly, [2] was again is described as "was interpreted at the time as indicating the feature would be withheld from Bundle
Read the rest
r because Heroku had failed to pay Ruby Together.". This is not at all how I read it — the comment just says that the open source project has priorities and not all of them can be implemented given the level of funding it has.
These are just two examples, but the article is riddled with wording like "blatant copying", "brazenly hypocritical", "was interpreted as [a bad thing]" etc.
I just feel like reading a clearly lopsided political piece intended to incite negative emotions towards something/someone. There are just enough facts to make it sound fact-based, but enough of author's own feelings and interpretation that I'm not at all convinced.
In fact, towards the end the author even states that there's been ~6 years where nothing of note happened, before the current drama. That seems like a relatively healthy situation?
[1] https://github.com/heroku/heroku-buildpack-ruby/pull/385/com...
[2] https://github.com/rubygems/rubygems/issues/1811#issuecommen...
Aaron is employed by Shopify. Also I *think* he was part of the shopify team that took over some responsibilities and/or on-call, see here for the sudden commits after a very long break: https://github.com/rubygems/rubygems/commits/master/?author=...
In Why I'm not rushing to take sides in the RubyGems fiascoFrom TFA:
> Let's get some kind of committer agreement in place with those folks who need access (the same way many other high profile open source projects have), and remove access from those who don't, while still being fully open to accepting PRs and being open to re-welcoming them as committers if they decide that is how they want to spend their time in the future.
> Here's the challenge. How do you tell someone that has had commit and admin access to critical infrastructure long after that need has expired that you need to revoke that access without upsetting them?
deivid-rodriguez's last commits were Sept 18: https://github.com/rubygems/rubygems/commits/master/?since=2...
With 7873 commits since 2018 he's 2x over the second one and crushingly the most active contributor since then: https://github.com/rubygems/rubygems/graphs/contribu
Read the rest
tors
However you slice it, none of that fits into TFA's above narrative.
His access being revoked can only be described as complete bonkers.
She has some PRs merged in, but nothing that shows me she should have elevated rights in the repo.
https://github.com/rubygems/rubygems/pulls?q=is%3Apr+author%...
In Ruby Central's Attack on RubyGems [pdf]According to the author's PR where she removed herself as a maintainer, she lost commit access.
https://github.com/rubygems/rubygems/pull/8987
In Ruby Central's Attack on RubyGems [pdf]Who? Everyone I recognize is continuing to contribute. https://github.com/rubygems/rubygems/graphs/contributors?fro...
In Ruby Central's Attack on RubyGems [pdf]Yes, this is due to the effort to extract stdlib code into gems https://stdgems.org/
In your case, StringIO use to just be stdlib code so bundler (or rubygems) uses it. Later on it became a gem, so by requiring it before reading the Gemfile, bundler run into this problem of already having loaded the wrong version.
Everytime this happens the bundler team has to modify bundler, and as a user the fix is to upgrade bundler.
You can see they had to vendor a lot of code from default gems to avoid this problem: https://github.com/rubygems/rubygems/tree/c230844f2eab31478f...
In Rv, a new kind of Ruby management toolRubyGem's Gem:SafeMarshal buffer overrun with length larger than fit into a byte
1 points · Open discussionShowing the 15 most recent of 44 sources. Enable JavaScript to search and browse every indexed mention.