Problems running bundler installed standard and rubocop #340
Comments
|
That's a very old version of Standard (one that had a more relaxed constraint on rubocop, which is why Bundler's solver apparently picked it. Please try running |
|
If you add standard to your Gemfile after installing rubocop, you may end up with this ancient version which does not have an upper version bound for rubocop. Subsequent versions of standard have max bounds on the rubocop version so if the Gemfile in your lockfile is too high, bundler will calculate that the ancient standard is a compatible version 😅 |
|
Yeah I ran into this too. Took some googling to get here, but it gave me the first impression of an abandoned project. Maybe standard could release one special version in between serious releases (like rspec did with 2.99) which is compatible with all rubocop versions but just prints an instruction of what to do? Seems to me that switching from rubocop to standard is quite natural and it did not occur to me to remove the rubocop gems first |
|
That's a good idea @markijbema. It seems like our options are pretty limited. We should probably consider a new release:
Thoughts? |
|
Are there cases when standard is loaded outside of the context of
If so, then I guess it would make sense to avoid raising on load. Otherwise, raising on load would reduce the noise of the subsequent slew of rubocop errors. |
No, but anyone who doesn't have |
|
Working on a version I've drafted this message and think it should run on postinstall as well as with every run of the CLI or rake tasks UPDATE: Simplifed the message UPDATE 2: Simplified again Feedback on this message? |
This is to mitigate the risk identified in #340
|
Message is great. The problem is clearly explained as is the fix. Small typo: There's an extra "when" in the "What's going on here?" section that should be removed:
|
|
Okay, I've released v0.0.36.1 If you add You'll see the same message printed whenever the |
|
Might I be so bold to suggest yanking all gem versions of Standard prior to 0.0.37? On one hand, it’s possible that someone has a production deployment locked to one of these versions, which are now more than 4 years old. On the other hand, Standard shouldn’t be part of the production bundle and if you try running that version of Standard you get: All versions of Ruby prior to 3.0 are EOL as of March 31, 2023, so anyone using this code is not only running a badly outdated version of Standard, they are also running a known insecure version of Ruby. If yanking Standard breaks someone’s deployment, that’s probably a good wakeup call to update Ruby before something much worse happens. For your convenience, here is a command to generate a list of all the gem versions that should be yanked: According to Rubygems, people have run into this issue nearly 5,000 times over the past 4 months. |
|
@sferik thanks for this comment, Erik. This is really tough for me, because I am a pretty firm believer that package repositories should be write-only and relied upon as immutable as a matter of principle. But the practical reality of how Bundler's solver currently works is that the existence of these old releases is causing a significant amount of harm to people for (if I'm being honest) an at-best theoretical benefit of keeping every release up in perpetuity on RubyGems. After thinking about it overnight, I'm 👍 on doing this. |
Don't have enough context here but from a random Homebrew maintainer's perspective: anyone using |
|
Brownouts first? A new version 0.0.36.2, released now, could start intentionally breaking a few CI builds starting in (say) October. Just 10% of builds on weekends at first. With a verbose message saying to upgrade (or remove) itself. But it could steadily expand the days of the week / percentage, until (say) April 2024, the fifth anniversary of the dependency fix, when it breaks all builds. |
|
@jamiemccarthy it is already a blackout. 0.0.36.1 intentionally disables the CLI and exits nonzero |
|
My 2 cents: Status quo
Yanking flips who's helped / hurt. |
|
Yes, thats the tradeoff, but I am dubious that there are any actual users depending on 0.0.1 to 0.0.36. As a result I believe more people are harmed by the current state than are helped Is there a way to query RG.o for version downloads over a time range? |
Okay, then I'd feel less bad about yanking. It might not hurt to put the phrase |
|
@jamiemccarthy agree. My plan would be to lock a Gemfile to 0.0.36 before yanking, yank, then copy the resulting error message into the README |
@MikeMcQuaid Yanking existing gems should only affect new production deployments. I suppose it’s possible that some number of people deploy a 4-year-old version of Standard into production on macOS, but I suspect that number is somewhere between non-existent and vanishingly small. If someone already has the gem installed locally, they can continue using it, even if it’s yanked on Rubygems. If at some point, they decide to reinstall their app/library or update their Ruby version, PS: Thanks for taking this feedback. I’m happy to see swift action on this. 😊 |
@searls When attempting to install a yanked gem using When attempting to install a yanked gem in development via When attempting to install a yanked gem in production via |
@searls I’m pretty familiar with the Rubygems.org API and I don’t believe this is possible. (It is however possible to query for downloads all time for a particular gem version.) I assume you want to check how many recent downloads there have been of Standard gems earlier than 0.0.36.1? The easiest thing is probably just to check the download stats, write the results somewhere, and check again some period of time later to get a sense of the rate. Here is a snapshot for today (taken at approximately 2:25 PM Pacific Time):
For your convenience, here is an alternative version of the command with CSV output: |
|
Okay, I ran the scripts again approximately 25 hours later and calculated the diffs. Here are the results. In summary:
By comparison, the latest version of Standard (1.30.1) has been downloaded 227,650 times since its release on July 7, 2023, for an average of 5,650 non-bot downloads per day. Does this make you reconsider your thinking about yanking 0.0.36?
Here’s the data in CSV format if you want to play with it yourself: |
|
It's interesting that So, no, this doesn't change my mind but the data is interesting. I think I'd rather rip off the bandaid now that you've had me thinking about this and be prepared to help people deal with the error messages |
|
Ok, this is now done. I've gone through and yanked all versions prior to 0.0.37, which contained an unbounded ( Thank you very much to @sferik for the kick in the pants and the detailed analysis, data, and instructions on how to do this gracefully. I also updated the README to feed google for anyone who runs into errors trying to install old versions. |
Gemfile:
resolved to Gemfile.lock
When running:
The text was updated successfully, but these errors were encountered: