Provide a way to turn ruby_dep errors into warnings

[Confusion]

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.

[e2]

If you can't use a newer version of Ruby, it's best to switch to older
versions of gems for that version.

Here, you have 2 options:

1. Lock to a different major of Listen, e.g. 3.0.8 should work for you
   (and report+request any bugfixes not applied there or new issues -
   I'll be happy to backport bugfixes so you can still get updates as
   3.0.x version)

2. Recent versions of Bundler may actually revert to an older version
   of Listen (e.g. 3.0.8) for you automatically if it detects that the
   current Ruby is not supported. I've seen this work, but I'm unsure if
   the functionality works well enough (pre-release version?). Of course,
   if you're using Travis, you may have to make sure that version of
   Bundler is installed there first.

Overall, it should be an expected feature of Bundler to resolve
situations where the recent version of a gem doesn't support the
current Ruby version.

The Bundler team is awesome in working on this functionality - please
support them in getting this working flawlessly and releasing official
versions of Bundler to support this.

If you really want to use Ruby < 2.2.5 on the latest version of
Listen, the best option is to fork the project and patch it. That's
because if you want to support an unsupported combination, you should
have the freedom to do so. (While I should have the freedom not to).

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
patch and release 3.0.x versions. I won't spend too much time testing
that branch for issues, though.

Philosophically, supporting older versions of Ruby is a HUGE burden
for everyone. It's also no fun (which severly discourages contributions).

The idea here is to "divide and conquer" - so that developing new
features has less backward-compatibility burdens, while support is
still possible and conscious and based on real use cases.

In short, you have a use case that's cheaper for you, but extremely
taxing for everyone else. I want to make sure I can help you in a
reasonable way without having the burdens, responsibilities leak back
into mainline development.

You will have to upgrade Ruby at some point anyway (unless you expect
your project to die before that happens). It's very rare that
upgrading later is cheaper - so it's better to keep errors like these,
so you can report situations like this, so I can get to understand
them better.

Let me know if that helps.

BTW, why can't you upgrade from 2.2.4 to 2.2.5? What kind of limits
are preventing that? Is it deployment costs? Too much paperwork?
Insane deadlines?

On Thu, Sep 29, 2016 at 11:24:34PM -0700, Ivo Wever wrote:

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.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#25

[Confusion]

Philosophically, supporting older versions of Ruby is a HUGE burden for everyone.

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 bundle update were solved relatively quickly (locally install newer Ruby version, bundle update now succeeds, grep .rvm gemset directory for the error message, figure out it was a gem called ruby_dep, read README, grep some more, figure out Listen is the gem using it, clone repo, run git blame to find out when ruby_dep warning was added, see if bundle update works with version pinned to older Listen), but the same error will be extremely frustrating to a less experienced Rubyist (and actually I didn't run into it, but a less experienced colleague, who indeed had a hard time figuring out what was wrong).

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:

• Keep Listen at 3.0.8 or similar. That's a totally fine solution, but it was initially entirely unclear to me that that was a solution and it took me a while to figure out. If the error message had immediately told me that I was attempting to upgrade to a Listen version incompatible with my Ruby version, and ideally a link to a page where compatibilities of gem versions with Ruby versions were listed, the experience would have been much better. Hence Mention failing gem in error message #24.
• Using a Bundler version that would have prevented the error. Before attempting bundle update I upgraded to the latest bundler, so it seems current released Bundler versions do not take Ruby version dependencies into account. It may be an expected feature, but as long as it's not there, people will run into ruby_dep errors.
• Fork Listen and patch it. Surely we don't want to get into the situation where many popular projects have public forks that do nothing but remove the ruby_dep raising of errors, because they actually work with Ruby 2.2.4 just fine, but they don't allow being installed under Ruby 2.2.4? But this would probably not happen and instead the next point would be implemented.
• Monkey-patch ruby_dep. I think that's exactly what will happen if ruby_dep is as strict as it currently is and does not provide an 'escape hatch'. Someone will build a 'ruby_dep_errors_to_warnings' gem, or perhaps 'disable_ruby_dep', whose sole function is to change 'ruby_dep' functionality. I think that would be very unfortunate and is the reason I opened this issue. If the gem itself provides an escape hatch, no one will start a counter movement and the ecosystem change promoted by this gem can be made.

BTW, why can't you upgrade from 2.2.4 to 2.2.5?

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.

[e2]

@Confusion - Lots of good points, thanks.

(I was crushed with work for 9 days so I didn't get to respond earlier).

If there was an rvm release that could install 2.2.5, we would have upgraded.

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.

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.

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).

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.

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:

listen 3.0.x and listen 3.1.x + ruby_dep 1.4.x, where the first combination is an "escape hatch" for people who really can't upgrade. If they want updates, they can ask for backports. (No problem on my side).

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:

1. Patches for Bundler/Rubygems for better messages and even smarter version constraint handling (but users would have to upgrade Bundler and Rubygems)
2. Patches for RVM/Ruby/Homebrew/whatever to help people upgrade Ruby faster and with more confidence
3. Effectively communicate the above. (I'd really appreciate help here - and even PRs for README's or changes in Wiki pages would help - especially reducing text).

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.

There's already this:

https://github.com/e2/ruby_dep/wiki/Disabling-warnings#disabling-by-requiring-a-special-file-since-rubydep--14x

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.

[korny]

Solved it by adding

gem 'ruby_dep', '1.3.0'

to my Gemfile.