ruby_dep breaks builds

[nightscape]

Hi all,

the idea of ruby_dep is nice per se, but I don't think it should be guard's (or listen's) responsibility to break builds because your Ruby version is outdated (that's a little like going to the bakery and they don't give you any cake until you've installed security cameras in your home :smile:). If I want that functionality, I can depend on ruby_dep myself.

Please consider removing ruby_dep as dependency from listen.

Thanks!

[e2]

@nightscape - I'm repeating myself, so I'll stay short. Ask follow up questions if you want.

Breaking builds is ok. Breaking production is not. Testing any Ruby < 2.2.4 doesn't make sense. (Maybe JRuby 2.2.3 from 9.0.5.0 is ok, since that version doesn't have the 2.2.4 vulnerability).

By your analogy, you're demanding a baker to support making cakes that were banned by the FDA as a health risk. Not to mention expired as well.

The point of ruby_dep is to make sure people don't use Listen with a version of Ruby that it doesn't work with.

There's no reason to "want" Travis builds to "work" on outdated Rubies. It's not like anyone is paying money for those old builds to happen. (If that's the case, I'd like to know how to do that myself...).

It doesn't make sense to e.g. expect Listen 3.1 to work on Ruby 1.8.7. The same with Ruby 2.0, 2.1 and 2.2.

It also doesn't make sense to expect Listen to upgrade without upgrading Ruby. That's a "double standard". (That Ruby doesn't need to be upgraded, but that Listen must be).

Also, upgrading Listen doesn't make sense if you're using an old version. Upgrading is dangerous when you're aiming for backward compatibility.

Again, it doesn't make sense to run a Travis build on an old Ruby and expect library upgrades to work. And if they don't work, that's good thing, because it meant that previously an unsupported combination of Ruby+library wasn't detected.

I need a compelling use case and "broken Travis build" is not a use case.

[e2]

Right now I need ruby_dep to actually avoid issues with declaring an unsupported Ruby as supported.

It creates the gem's required_ruby_version from enabled versions of Ruby tested on Travis. This is to avoid people complaining about Listen being declared compatible and not even tested on Travis at those versions.

Again, supporting anything other than MRI < Ruby 2.2.5 is a security risk. Travis lets you use outdated rubies. But there's no reason Listen should.

Also, even JRuby didn't work with Listen properly until yesterday. And it still doesn't (build fails). It's installable since yesterday, but at least people get a warning if they use MRI 2.2.3.

At this point, I could write a book about why expecting Travis builds "not to break" doesn't make sense. And I'm sure you don't have time to read one.

"Broken Travis builds" vs "protecting users and tons of other benefits" - I'd pick the latter. Most people are shocked that MRI < 2.2.4 shouldn't be used at all.

Not to mention development gets harder when supporting Ruby 2.3.x alongside others and using RuboCop.

So a broken build is actually "works as expected". (In that it protects users from shooting themselves in the foot).

[e2]

So summarize, I'm closing because it's needed to:

1. Prevent Listen from being installed on an unsupported/untested Ruby version (version constraint)
2. Encourage users to move away from buggy/vulnerable Rubies, so there's less misguided pressure for "backward compatibility" on maintainers/developers (showing warnings)
3. Prevent past mistakes, like not declaring the supported Ruby version accurately, clearly and consistently
4. To have more time to honor actual backporting requests without making "backward-compatibility" the default.
5. To educate people about SemVer and good devops practices.

[nightscape]

In our case the following occurred:

• We have some gems which we develop internally
• Those gems have their Gemfile.lock .gitignored as is the recommended practice
• The version dependency on guard is relatively loosely specified, as it's only a development dependency and we just roll along with its updates (sometimes fixing minor things in the Guardfile)
• The main (non-development) dependencies have stricter version restrictions
• Some days ago, suddenly builds started breaking for no obvious reason and only after researching for several hours we found out what the cause is, what this ruby_dep gem is, what it does and that it is required by listen which in turn is required by guard
• In our special case, the Ruby version that caused the build to break was not even the Ruby version that is running the tests or production, but is just used to bundle package gems before adding them to a Docker container (yes, in an optimal world we would use the same version, but it never was a problem up to this point)

What I want to make clear is that for many users

• builds will start breaking completely unexpectedly
• by initially unclear causes
• by a gem that is a tool and not a core dependency (and imo should not be "policing" on its users)
• although I'm a big-time fan of guard, I'm currently having a lot of convincing to do in order for developers to not just throw out guard altogether

While I understand and like the core idea and its intention, I just don't think that guard/listen is the right place to start this battle.

[e2]

Some days ago, suddenly builds started breaking for no obvious reason and only after researching for several hours we found out what the cause is, what this ruby_dep gem is, what it does and that it is required by listen which in turn is required by guard

You could've just opened an issue and asked. Or, you could run something like:

$ for k in $(gem list --no-versions); do gem specification $k|grep -q ruby_dep && echo $k; done
listen
ruby_dep

Or, you could even hire me to investigate.

(yes, in an optimal world we would use the same version, but it never was a problem up to this point)

Don't mention that to the devops people, or they won't sleep at night...

builds will start breaking completely unexpectedly

This is a good thing. A broken build is a production catastrophe avoided.

by initially unclear causes

Just ask.

by a gem that is a tool and not a core dependency (and imo should not be "policing" on its users)

Which actually is better to have such issues surface in development than during deployment. For other users, such protection could've prevented major problems. E.g. once upon a time I started aborting if symlinks causing filesystem loops were detected. Lots of people complained about the errors in their projects. But this was intended for those who had 100% CPU usage and weren't extremely technical enough to find out why. I can't make everyone happy, but I can avoid at least the most painful catastrophes.

And a "broken Travis build" is probably as far from a catastrophe as you can get. It's a fail-safe doing it's job.

although I'm a big-time fan of guard, I'm currently having a lot of convincing to do in order for developers to not just throw out guard altogether

And I have a ton of convincing to do to get people upgrading their Ruby version - which would've prevented the problem already.

Personally, I don't really get a major benefit from having "more Guard users". I'd rather prefer elite professionals to benefit more. And so I'd be glad to support whatever cutting-edge tech is available (e.g. Ruby 2.3.1) rather than keeping outdated servers still running.

Also, there's no other way for me to encourage users to update their Rubies.

While I understand and like the core idea and its intention, I just don't think that guard/listen is the right place to start this battle.

I'm open to compelling alternatives. I think a development tool is a good place to start. Notice that RuboCop already takes Ruby versions into account. And Guard supports RuboCop through Guard::RuboCop.

What still shocks me the most is that even in such a technical field like software development, there are no technical debates around supporting older versions of Ruby.

And so if this battle isn't a technical one, it's a battle against things like maybe ignorance, laziness, etc. And for those, I think preventing installs and warning about vulnerabilities is a good step forward.

Sure, it's a huge cost for me to deal with complaints here (which I'm not paid for) ... but it's still less expensive than the alternative.

Even in terms of costs and benefits - would dropping the dependency on this gem results in more contributors eager to help out with: https://github.com/guard/guard/issues or https://github.com/guard/listen/issues? Very unlikely. Not to mention: most of them are feature requests, so they require writing new code. And why should that "new code" be written with an "old interpreter" in mind? Especially if Ruby 2.2 will already become "old" once the benefits of 2.3.1 get in high demand.

It is a battle. But then again, it is a battle for what's right. And it's not really a battle, because I'm not shutting off any choices. "Can't install on older Ruby on Travis when the gem isn't locked" is not a choice here - just a bad habit. (Even in devops terms).

Again, you can always open an issue and ask for help. If a PR is rejected (very rare), it's likely with a compelling explanation.

[e2]

FWIW, I started a wiki page about this: https://github.com/guard/listen/wiki/Support-for-older-versions-of-Ruby