-
-
Notifications
You must be signed in to change notification settings - Fork 2k
bundle install should force installation of yanked gems in the Gemfile.lock #2277
Comments
This needs:
|
I ran into issues while updating some gems today, so here are some use cases for the proposed solution. New Relic released a gem update that they then yanked, 3.5.6.46. This installed locally with a I also did an update from fog 1.8 to 1.9, with The proposed solution would allow the yanked versions to be deployed. Since whatever test suite/QA process was passed with those versions, it seems like an okay idea (though newrelic_rpm wouldn't be covered by my test suite). Obviously the current handling of yanked versions leaves something to be desired, and the problem is further exacerbated by my using of a different version of bundler than Heroku. Something needs to be done to make this work better, but I still can't say I'm sold on the idea of installing yanked gems based on Gemfile.lock, at least not as the default scenario. Presumably they were yanked for a reason. What about replacing Personally, I don't want bundler installing yanked gems/dependencies in the first place. If a gem is yanked after added to my Gemfile.lock, I want an easy way to revert back without having to add additional dependencies (eg. net-scp) to my Gemfile. |
This is still relevant. |
I can take this on, but it won't make it until post 1.6. |
I just opened an issue for rubygems about this: Didn't realize there was already an issue here (thanks for directing me to this, @sferik!). If it's easier I can close that issue and bring my suggestions over here. |
IMHO, the deployment problem is better addressed by Bundler than RubyGems. Even if RubyGems “fixes” it, it would still need to be addressed in Bundler. |
Sure, bundler definitely needs to solve the problem with |
My personal opinion is that yanking should be removed, and 'dangerous to install' gems get removed completely, while buggy gems simply get newer, higher versions. In the meantime, I think that installing locked gems even if they were yanked after the bundle was locked is the best thing we can do. On Fri, Mar 21, 2014 at 11:25 AM, Myron Marston notifications@github.com
|
@indirect Thats a good point. A gem maintainer can always revert some commits and release a higher version instead of yanking. Or failing that, end-users can lock a previous version in a Gemfile (I imagine yank predates bundler?). |
@indirect It would be great if maintainers used the current yanking functionality as you’ve percribed but there are three problems:
|
As of http://blog.rubygems.org/2015/04/13/permadelete-on-yank.html, this feature is no longer possible. |
Let me know if there's anything you need from me on the RubyGems.org side. I'll have some free time on Sunday to hack on this.
The text was updated successfully, but these errors were encountered: