-
Notifications
You must be signed in to change notification settings - Fork 7
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
Provide a way to turn ruby_dep errors into warnings #25
Comments
If you can't use a newer version of Ruby, it's best to switch to older Here, you have 2 options:
Overall, it should be an expected feature of Bundler to resolve The Bundler team is awesome in working on this functionality - please If you really want to use Ruby < 2.2.5 on the latest version of Another option is to just monkey-patch RubyDep during runtime. Again, Listen 3.0.8 is for you. If there's a serious bug, I'll likely Philosophically, supporting older versions of Ruby is a HUGE burden The idea here is to "divide and conquer" - so that developing new In short, you have a use case that's cheaper for you, but extremely You will have to upgrade Ruby at some point anyway (unless you expect Let me know if that helps. BTW, why can't you upgrade from 2.2.4 to 2.2.5? What kind of limits On Thu, Sep 29, 2016 at 11:24:34PM -0700, Ivo Wever wrote:
|
I understand the motivation for ruby_dep and I agree it would be a good thing if gems were explicit about the Ruby versions they are tested with and which they support. I also agree it would be amazing if Bundler could automatically install versions of gems compatible with the Ruby version you are using. However, I currently see a major problem with ruby_dep: the experience users have when they first run into errors raised by it. I'm experienced enough that the problem I encountered during the referenced attempt at a I'm actually surprised you haven't yet received rants by people frustrated by errors raised by ruby_dep and demanding you don't do this. No matter how good the intention and idea, it's about perception and user experience. As for solutions to this: that's why I opened #24 and this issue. Let's discuss the solutions you propose and their relation to #24 and this issue:
If there was an rvm release that could install 2.2.5, we would have upgraded. As it is, we decided to wait for a release, as using 2.2.4 is not a problem for us. In the mean time I thought I'd at least upgrade our gems. And that failed unexpectedly, in a way that was pretty involved to figure out. We're fine with keeping Listen at an older version, but if other projects start using ruby_dep, bundler still wouldn't resolve things correctly and pinning many gems to compatible versions becomes a hassle, then there will come a moment when I will write code to get around ruby_dep version checks. And if I would do that, so would others. And then a gem would be born. And soon many people would start using it, maybe even depending on it and ruby_dep would become pointless. In the worst case an arms race would start. Given the reality pointed out by @zetetic in #20, that many companies are unable to upgrade Ruby, but still sometimes want newer gems, for whatever reasons, bad or bad, what do you expect to happen if ruby_dep gets used more? My expectations are outlined above and I basically think ruby_dep is doomed to fail if it more people have the experience I had last week. |
@Confusion - Lots of good points, thanks. (I was crushed with work for 9 days so I didn't get to respond earlier).
I installed 2.2.5 using RVM some time ago - so I was surprised it doesn't work. If you have a link to the issue, that would help. Ruby 2.2.5 has been out for over 5 months, so to me it's unbelievable that there's a problem installing Ruby 2.2.5 through RVM. Then again, I usually use RVM master.
At the minimal I try and stay available to accept pull requests. If someone suggested supporting Ruby 2.2.4 due to the temporary RVM problem (and for as long as there's not released RVM version to handle 2.2.5 on all platforms), I'd create ruby_dep 1.5 including Ruby 2.2.4 support. What makes this situation special is that people want Ruby 2.2.4 because RVM is broken. That's a fix very far from the problem. If it takes RVM 5 months to support 2.2.5 (a Ruby which fixes a long list of bugs) ... I don't know how to handle that. I understand upgrade problems with complex deployments - so it seemed like upgrading from 2.2.4 to 2.2.5 would be trivial if not absolutely essential (given the risk of having lots of known bugs).
That's why I'm so grateful you're spending time to explain to me. Even now I have to maintain 2 sets of gem versions:
The problem seems complex and it's very hard to communicate in just a few words. The README here should help: https://github.com/e2/ruby_dep/blob/master/README.md - let me know if I can make it any better. What I find myself constantly returning to is: if Ruby can't be upgraded, then the world is already broken. And in a broken world it's unreasonable to expect things to work properly. And so it doesn't make sense to create an easy and convenient path towards a broken world. Or, shorter: "if you can't upgrade Ruby, don't upgrade gems". Or, "if you can't upgrade Ruby from 2.2.4 to 2.2.5, then something is fundamentally wrong elsewhere". The errors users are getting are pretty much handled by Rubygems and Bundler - so they would have to be fixed. So the bad experience comes from users not knowing how to side-step the error without updating Ruby. That's already not a good goal. I can't quick-fix Bundler/RubyGems and I can't fix the Ruby upgrading process. I could submit PRs to either of those, but I have to know what's broken and what would help users. I also don't want to tell users to downgrade to Listen 3.0.x, since they'll stop getting automatic updates. (Which should be fine if they decided they don't want an updated Ruby either). So I see 3 decent solutions:
There's already this: And that silences warnings. But as for errors, they happen before RubyDep is included, so I can't do anything about it. If a gem requires Ruby >= 2.3.0, and that gem is a dependency, then other projects will result in the same bad experiences you described here. |
Solved it by adding gem 'ruby_dep', '1.3.0' to my Gemfile. |
In the situation of guard/listen#409, also mentioned in #24, ruby_dep signalled an issue that was not as fatal to us as the error, which caused a
bundle update
to fail, would make it appear.Listen is a dependency-time gem for us, and if it has only been tested on 2.2.5 and only aims to support 2.2.5 then it is still acceptable to us to attempt using it using Ruby 2.2.4. If the gem truly fails with that Ruby, that is on us to deal with, having explicitly chosen to accept that risk.
So in such situations it would be helpful if there was some way to tell ruby_dep to issue warnings instead of errors. Perhaps on an individual basis (per gem raising an error), requiring e.g. Gemfile declarations in which the user explicitly turns the error for a specific gem into a warning. It would be a very explicit way in which users can say: I know about and choose to accept the risk that ruby_dep warns me about.
The text was updated successfully, but these errors were encountered: