Describe the problem as clearly as you can
bundle config set ignore_messages.<gem> true suppresses all post-install messages from that gem, forever. There's no way to silence one specific message while still seeing a different message the same gem prints later (e.g. a new deprecation notice, or a security warning).
In practice this means teams either live with a message they've already read on every bundle install, or they opt out of that gem's post-install channel entirely and risk missing something that actually matters in the future.
Common real-world examples: readline and httparty both print a post-install message that has stayed identical across many releases. Once you've read it, there's no benefit to seeing it again on every install — but fully ignoring the gem means a genuinely new message (a security notice, a breaking change) would go unseen too.
Did you try upgrading rubygems & bundler?
Yes — reproduced on the latest release.
Post steps to reproduce the problem
- Add a gem with a
post_install_message to your Gemfile (e.g. httparty).
- Run
bundle install. Note the message prints every time.
- Run
bundle config set ignore_messages.httparty true.
- Run
bundle install again — the message is gone, but so would any future, different message from that gem.
Which command did you run?
bundle install / bundle config set ignore_messages.<gem> true
What were you expecting to happen?
A way to suppress a specific message (e.g. by exact text or a digest of it) so that only that message is silenced — if the gem later changes or adds a different post-install message, it should still show up.
What happened instead?
ignore_messages only accepts a gem name and suppresses every message from that gem indiscriminately, with no content-level granularity.
Proposed API, for discussion:
bundle config set ignore_messages.httparty.<message-digest> true
A digest (e.g. SHA of the message text) matches on the message itself, so it keeps working even if a gem changes its message without bumping the version, and doesn't require Bundler to reason about version ordering.
We considered scoping suppression to the gem version instead (ignore_messages.httparty.<version> true), but ruled it out: gems like readline and httparty keep the same message across many releases, so per-version scoping would force you to re-suppress on every upgrade even though nothing changed — the opposite of "set it once and only hear about it when it's actually new."
Environment
Bundler 4.0.19
Platforms ruby, arm64-darwin-23
Ruby <any>
RubyGems 4.0.19
Describe the problem as clearly as you can
bundle config set ignore_messages.<gem> truesuppresses all post-install messages from that gem, forever. There's no way to silence one specific message while still seeing a different message the same gem prints later (e.g. a new deprecation notice, or a security warning).In practice this means teams either live with a message they've already read on every
bundle install, or they opt out of that gem's post-install channel entirely and risk missing something that actually matters in the future.Common real-world examples:
readlineandhttpartyboth print a post-install message that has stayed identical across many releases. Once you've read it, there's no benefit to seeing it again on every install — but fully ignoring the gem means a genuinely new message (a security notice, a breaking change) would go unseen too.Did you try upgrading rubygems & bundler?
Yes — reproduced on the latest release.
Post steps to reproduce the problem
post_install_messageto yourGemfile(e.g.httparty).bundle install. Note the message prints every time.bundle config set ignore_messages.httparty true.bundle installagain — the message is gone, but so would any future, different message from that gem.Which command did you run?
bundle install/bundle config set ignore_messages.<gem> trueWhat were you expecting to happen?
A way to suppress a specific message (e.g. by exact text or a digest of it) so that only that message is silenced — if the gem later changes or adds a different post-install message, it should still show up.
What happened instead?
ignore_messagesonly accepts a gem name and suppresses every message from that gem indiscriminately, with no content-level granularity.Proposed API, for discussion:
A digest (e.g. SHA of the message text) matches on the message itself, so it keeps working even if a gem changes its message without bumping the version, and doesn't require Bundler to reason about version ordering.
We considered scoping suppression to the gem version instead (
ignore_messages.httparty.<version> true), but ruled it out: gems likereadlineandhttpartykeep the same message across many releases, so per-version scoping would force you to re-suppress on every upgrade even though nothing changed — the opposite of "set it once and only hear about it when it's actually new."Environment