-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'call for update' to RubyGems install command. #5922
Conversation
e5a0343
to
3476aad
Compare
Very nice work, thanks for setting this up! |
3476aad
to
c22126c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome improvement! And great careful user-focused approach 😍
@simi Is this still a WIP or is it ready for review? |
It is awaiting |
Thanks, that's what I thought but I wanted to make sure :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻 🙌🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of comments. Also I wonder whether this "call for update" message would make sense in other commands other than gem install
. But regardless of the answer to that, gem install
seems like a good place to start!
This is awesome by the way!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me and I think it's an impressive piece of work! 💪
How should we ship this? Standard patch release, or wait for new years?
I'd go with shipping it right now with the next patch, but happy to do otherwise! End of year is so close anyways!
Thanks for the kind words. I was looking around and it seems similar changes were released in other projects on minor release. I would prefer the same, but I'm not sure if we can just upgrade minor version simply at any time. If that's problem, I think we can roll it out actually with next patch version. The scope is super limited and it would be great to get some community testing before new Ruby release, since if I understand it well, that's how majority of RubyGems installations are upgraded (when upgrading Ruby version). I do aim to prepare bundler support for same feature as well before Ruby 3.2 release. 🙏 |
Let's ship this with RubyGems 3.4 then. I expect to release than at the beginning of December, so we have about a month to test before final Ruby release. Merging this now! |
Thank you for asking. oracle/truffleruby@f6d2715 is an example of a change I needed to make to RubyGems, and that of course gets lost if Rubygems gets updated. IMHO any such message is just annoying no matter for which Ruby, but that's my personal opinion. At least since it's only shown on BTW this message should also not be shown if where RubyGems is installed is not writable. For instances this message is not actionable for a Ruby installed by apt/dnf under /usr (isn't it?). Unless that's already handled? |
@eregon I'll update to print out message only on CRuby for now.
We're doing our best to keep it as friendly as possible. There is no impact on the
It is recommended to prevent any If you think 1 week is still annoying, we can double that. I would be ok with that. We're following same pattern as similar CLI tools do already for years. Personally I had no problem with npm/terraform/gh cli printing out those messages from time to time. It is good notification of thinking about the upgrade (not only locally, but also on project side). |
Nice, I think I can use this in
I think no need to change, and probably would be good to have opinions from more people. I know I'm rather biased on this matter. |
OK, I'm going to keep it as is. |
/cc @headius |
@simi I somewhat agree with @eregon opinion on these messages and that I personally would only want to see a message like this if it fixed something I should-not/cannot ignore like a security update. If I am using an older version of something I typically have a reason for it. Rubygems release stride is also pretty quick so I think people will be seeing this message once every couple of weeks (RG averages about 2 releases a month) from just new releases. If you change the re-notification period to once every two weeks the odds are higher they will only see this once per RG udpate. If we do not want to see these by default on JRuby we can just put |
👋🏻 hi. As the main maintainer for the Ruby Buildpack for Heroku I care about RubyGems quite a bit. Our policy (https://devcenter.heroku.com/articles/ruby-support) is currently:
Basically we never re-install the rubygem. If someone wants a newer rubygems version they need to upgrade to a newer Ruby. This is great for consistency but is somewhat annoying in cases where there are large updates on RubyGems but there's no associated release of MRI. Also the version support between RubyGems and MRI somewhat differs. With the addition of this prompt I can see a few paths forward:
For this last option "Let the customer define a rubygems version." ideally it would be pinned to their local development environment in the same way that I think my two favorites would be |
sudo gem install cocoapods |
@schneems can you explain how this affects Ruby Buildpack for Heroku? Message is skipped on non-tty environments and by doing local upgrade there is no change to any of the files (including Apart of that, |
? |
@enebo By setting |
I missed that it's only for non-tty environments. I guess i'm using this as an opportunity to talk about what our support SHOULD be as i'm re-writing the Ruby Buildpack in Rust and nows the time to make changes. One big change we're making is relying on the bundler version in the Gemfile.lock instead of stripping it out. Feel free to disregard the rest, as it's mostly for your information. I'm mostly latching on to this conversation to have a related but different one.
The only guarantee of behavior is specific bundler, ruby, and rubygems version. Right now we lock down on Ruby, in my upcoming buildpack, we'll lock to the customer's bundler version, that just leaves RubyGems as the odd duck out. When Bundler 2 came out there were TONS of problems with it's RubyGems and Ruby version support. It basically caused a 3 dimensional matrix of possible problem cases and we had no capacity to mediate the problem because we have no way of decoupling Ruby version from RubyGems version (at the moment).
We don't [provide] support for EOL Ruby versions, but we don't remove them either. The oldest version of Ruby on the Heroku platform right now is 2.4.10. So whatever we put in the buildpack needs to play nice with 2.4.10 or we need to otherwise have code that says "update rubygems version". Generally speaking there's never a case where customers won't need a specific version. RubyGems and Bundler and Ruby all have bugs in them, especially new releases. I try to be wary that (most) blanket decisions I make for my customers can be opted out of in some way. So if I move forward with auto upgrading everyone to the latest, I would still want some way to opt out of that behavior and I would want that to be supported by community tooling. |
@simi Yeah. I misread that. I guess we will just ENV["RUBYGEMS_PREVENT_UPDATE_SUGGESTION"] if we decide not to provide this with the rubygems we ship with. Looking at the PR there are other ways too. Whatever we do we want to be able to make someone be able to opt into this if they want it (if we decide to disable it by default). Thanks for the ping on this. |
It is actually only for TTY environments if I understand it well.
Feel free to ping us on Slack to get in sync about your expectations and your plans.
That's seems a good step. If I understand it well, the challenge currently is to detect proper Ruby. Once detected, you can install latest bundler (or keep the Ruby default if already supporting auto-install/switch feature) and let the bundler do its best to manage Gemfile.lock with proper version itself. |
@enebo If welcomed, I can add also special config for this so there is no need to manipulate ENV just because of this. |
@simi That's ok. Sorry I meant to reply to this a few days ago and it got lost in the tabs |
What was the end-user or developer problem that led to this PR?
Promote update of RubyGems, since it is not currently best practice to update local installations.
Mostly based on similar features in yarn and gh CLI. More info at https://bundler.slack.com/archives/C0HJMKWH4/p1639683555027700.
What is your fix for the problem, implemented in this PR?
I have added small banner to
gem install
command which is printed when all following conditions are met.gem install
command was successfulprevent_update_suggestion
entry ingemrc
fileRUBYGEMS_PREVENT_UPDATE_SUGGESTION
environment variabledisable_system_update_message
set (sincegem update --system
is blocked when set)gemrc
file is writable (empty one will be created during check to ensure if not present yet)I tried to avoid any links in the message to make it futrue-proof (since link can expire easily).
Plan for later is add similar to
bundle install
andbundle update
commands.Example
Make sure the following tasks are checked
closes #1620, #3096