Hide ruby_dep warnings without changing environment variables

[heaven]

Please remove the ruby dep gem from the dependencies list as it is not the task of this gem to check my ruby version. If I ever wanted I would add this gem to my gemfile myself!

As per the README:

The Listen gem listens to file modifications and notifies you about the changes.

Or please add a way to shut up these warning from rails environment configuration. I just want to use rails and want it to reload my code when I change it, I didn't ask anyone which ruby version to use and have reasons not to upgrade.

Thank you.

[e2]

Short answer 1: lock to Listen v3.0.8

gem 'listen', '~> 3.0.8'

This way you'll avoid ruby_dep completely. (But you'll have to track releases and bugfixes to Listen and ask for backporting those bugfixes into 3.0.x).

Short answer 2: silence the warnings

There's an environment variable that disables the warnings:

https://github.com/e2/ruby_dep#usage-to-solve-problem-2

export RUBY_DEP_GEM_SILENCE_WARNINGS=1

Details

If you have reasons not to upgrade, let me know (I'm curious - I always ask people). If you switch to 3.0.8, you should watch the release notes for Listen bugs in newer 3.1.x releases that may affect you. If you find any open an issue to ask for a backport to the 3.0 branch.

The Listen gem requires a newer ruby in the Gemspec anyway: https://rubygems.org/gems/listen/versions/3.1.5

Newer Listen version aren't tested on older version of Ruby. The ruby_gem dep handles limiting the Ruby versions in the gemspec based on which Ruby version are tested on Travis builds.

The ruby_dep gem is to prevent people from reporting known issues or unknowingly using vulnerable Ruby versions. If someone must use a vulnerable Ruby version, I want to know (because it affects Listen releases).

I didn't ask anyone which ruby version to use

The problem is: if you want to use any Ruby version, then I have to support EVERY Ruby version.

And doing so is a huge price to pay, given Listen's tests are massively resource-hungry, flakey, platform specific, complex and take a long time.

It's a HUGE benefit to limit the Ruby versions to only the latest.

Please let me know if I can improve the documentation on this somehow.

Thanks.

[heaven]

Hi,

The problem is: if you want to use any Ruby version, then I have to support EVERY Ruby version.

There's always required_ruby_version you can add to the gemspec. Users of older ruby versions would have to use an older gem version. And it would be good if this version would correlate with the ruby version required by rails.

Currently the gemspec requires >= 2.2.3, ~> 2.2, we have 2.3.0, which is supported. If you think it is vulnerable then you can create a new minor release and require >= 2.3.1.

Well, putting the gem as a dependency for rails requires some support, as there always will be users with older ruby/rails versions (plenty of them) which requires some of critical fixes to be backported. Just like rails does.

It's a HUGE benefit to limit the Ruby versions to only the latest.

Perhaps for you, as a developer, but how many production environments do use the latest ruby? We'll have to sit and upgrade all our servers all the time instead of making business :) This is not affordable for us. We upgrade once a year, maybe, or by a requirement (critical vulnerabilities/crashes, etc).

Long story short – for us this warning is useless and is quite annoying. The way to silence it with an env variable is not the best option for us, a config option in application.rb would be much better.

I'd like to see 2 types of notifications: notices and warnings, when first could be just notifications about fresh ruby versions with some improvements/fixes, the second one could be displayed in red and notify about critical vulnerabilities/exploits, etc. Something that requires immediate attention. And 2 options like config.silence_ruby_version_notices and config.silence_ruby_versions_warnings. I would silence the first one, at least for our big projects where we have 25+ servers.

Best,
Alexander

[e2]

There's always required_ruby_version you can add to the gemspec.

And that's what ruby_dep does. It creates a version constraint for the gemspec based on .travis.yml contents.

Users of older ruby versions would have to use an older gem version.

Yes - and Bundler is supposed to take care of that. The latest version of Bundler should resolve the dependencies so that an older version of Listen is selected if you have an older version of Ruby. This somewhat works, but if it doesn't file an issue/feature request in Bundler's issue tracker.

https://github.com/e2/ruby_dep/releases

If you think it is vulnerable then you can create a new minor release and require >= 2.3.1.

I'd get a lot of flack if I did that. A lot. That's why I have to mention vulnerabilities. It's much better for people to silence vulnerability warnings than for busy developers to spend lots of unpaid time supporting Ruby versions no one should actually be using.

If businesses are forced to use older versions (and are compensated to do so), it doesn't make sense for the rest of the world to cut back on development and progress to invest into maintaining and testing versions no one is supposed to be using.

The argument that "my job requires this" is weak one. I'd rather address the cause. If it's because Apple/Google/Amazon/Java/CloudSomething lists only vulnerable Ruby versions as available - and they're paid for their services - it doesn't make sense to pressure people who spend their free weekend time to do work they don't want to do and doesn't result in improvements for everyone else.

Supporting old versions is neither fun (at least for me it isn't) nor profitable (for me it isn't) nor beneficial for everyone else (except the few companies who can't afford to migrate or don't have that option yet).

Also there are tons of bugs fixed in every Ruby release. The worst waste of time is debugging something that was fixed in a later Ruby version.

I can't be held accountable for all the possible combinations of scenarios, Ruby bugs, and Listen minor versions available. And a lot of people rely on Listen working really well (which is very difficult to achieve).

Meanwhile, I'm ok with accepting justified patches and backporting bugfixes to people stuck with older versions of Listen. (I don't mind creating separate branches for 2.x and making releases - but expecting me to support Ruby 1.8 in the latest versions of Listen in my free time isn't a worthwhile contribution, even if it would make 1 person out there "happier").

And by supporting older versions of Ruby I'm preventing support for newer features in later Ruby versions.

Well, putting the gem as a dependency for rails requires some support, as there always will be users with older ruby/rails versions (plenty of them) which requires some of critical fixes to be backported. Just like rails does.

It's one line of code in a Gemfile to do so. And if someone is working with legacy gems, they should lock to patch-level versions of gems - and very carefully upgrade after reading release notes.

As for warnings, there are many people out there who can upgrade who don't. If they do, they immediately get lots of bugs fixed and a speed/memory bonus.

"Not upgrading" needs SERIOUS justification. Because it's adding more work for everyone, no benefit, it's disrespectful to people putting lots of effort into making new features fast, stable and bug, it hurts the community, it discourages contribution, it reduces resources for improvements, people stuck with old versions start acting like tyrants demanding compatibility support they feel they're entitled to, etc.

Perhaps for you, as a developer, but how many production environments do use the latest ruby?

That's what the warnings are supposed to change. The sooner people upgrade, the more total time will be spent working and testing those new versions and the lower the migration costs that hosting providers will force people to pay at some point anyway.

It's a cost to everyone. Companies should be taught to upgrade frequently. It fosters a better understanding of stability, security and reducing overall development costs. Staying stuck in old versions doesn't foster anything productive.

We'll have to sit and upgrade all our servers all the time instead of making business :)

Even for security reasons you cannot afford to not upgrade. Maybe the solution is to automate the upgrading instead? I'd rather worth to help that happen, than to manually e.g. convert Ruby 1.9 hash syntax to Ruby 1.8 syntax - just so someone else doesn't have to manually upgrade.

This is not affordable for us.

Then perhaps it's not a good business model if it requires people like me to work for free. Just saying.

It would be more affordable for me to actually help you upgrade.

Long story short – for us this warning is useless and is quite annoying.

It's useless and annoying to you, but it's very beneficial to the Ruby community as a whole. For example, Rails will greatly benefit from the 2.3 speed and memory improvements, also against DoS thanks to garbage collecting symbols.

Those things reduce the headaches and hosting costs of almost everyone using a Rails server.

The problem: getting people to upgrade to Ruby 2.3. The main disadvantage: people may feel gems may not work properly with Ruby 2.3.

The solution: making 2.3 as stable as possible by maximizing the work and testing there.

The way to silence it with an env variable is not the best option for us, a config option in application.rb would be much better.

Listen is pretty much "middleware", so it's designed to not interact with anything. It's not a command-line tool per say, so reading a "config file" doesn't make sense.

Meanwhile, for servers, it's typical to store configuration in the environment. Heroku pretty much stores ALL the configuration in environment. Lots of web developers use gems for reading/setting variables to/from the environment. So it's not unreasonable to have an environment variable.

And since Listen is used as middleware, it's hard to add options through any non-environment configuration, because tools that use listen would have to be aware of those options. (Which causes problems all the time).

I'd like to see 2 types of notifications: notices and warnings, when first could be just notifications about fresh ruby versions with some improvements/fixes, the second one could be displayed in red and notify about critical vulnerabilities/exploits, etc.

You can open an issue or PR in the ruby_dep project.

Colors can be a problem due to ANSI support workarounds in Windows - and that it needs to be configurable (turned of when logging, when not a terminal, etc.) and documented. Also, Ctrl-C handling would have to reset the terminal. (To avoid every following message to be red as well). If color wouldn't be on by default, people wouldn't enable it. If it was on by default, people would need multiple ways to turn it off. Including an environment variable. And it would need os detection too. Testing all that is quite tricky and time consuming. (Very hard to please everyone).

I would silence the first one, at least for our big projects where we have 25+ servers.

If you have 25 servers, you should consider using deployment tools. Things should be set up so that adding an environment variable to all servers shouldn't be a problem.

And 2 options like config.silence_ruby_version_notices and config.silence_ruby_versions_warnings.

To me, they're warnings, because if you don't have the latest Ruby, you're using a version with bugs that will forever potentially affect and threaten you until you upgrade. I can't decide if an IO.pipe error is harmless in your case or a security vulnerability. That's specific to your project.

I don't know if upgrading Ruby in your situation is important or if it can be ignored. So I can't make assumptions about how important it is. Except for assuming that it may be important. That's why it's a warning.

For you, it's annoying. For someone else - it saved their business.

RubyDep does 2 things: it creates a version constraint and warns if the Ruby version is vulnerable. The second more like a workaround for avoiding a complex version constraint - and for people where the constraint would be too restrictive. The warning isn't as much about the Ruby - it's a warning that your Ruby version may be soon dropped, so you may have deployment problems with Listen in the near future if you don't upgrade. Again, Bundler should handle this case gracefully, but I can't guarantee that.

If you want a config option in Listen to disable this, first create a PR in ruby_dep to disable them. It's also possible to disable the warnings from a Gemfile - by setting the :require option to require a file from ruby_dep that disables warnings by default.

You can always monkey-patch RubyDep to make the warnings method a no-op.

If you'd like a more convenient way to disable warnings in ruby_dep, just create PR and I'll be happy to help.

Thanks for spending time to share your thoughts - the whole subject has made a lot of people angry, but I'm glad no one was seriously affected by it. (And it is emotionally draining for me, because I do care).

It's a complex and controversial subject, so thanks to people like you I do get to work out how to explain the reasons, the problems and possible workarounds.

[heaven]

This is pretty much off topic. We do use deployment tools and clusters are configured with Chef, but upgrading ruby on all of our services is not a quick task.

As I said at the very beginning checking the ruby version is a task for ruby_dep, not the listen. All its internal dependencies could be resolved via gemspec (as all the other gems do) and there's no reason to bring ruby_dep and annoying us all the time, unless you want to force users to use this gem. Since we have no other choice it's pretty much feels like you do. Did we add ruby_dep to the Gemfile? No. Are we interested in adding it? No. Did anyone asked us if we are? NO. The reason not to upgrade is our private decission and is off the scope of the discussion.

Those interested can always add ruby_dep to their Gemfiles and stay updated and happy. We don't need this.

[e2]

We do use deployment tools and clusters are configured with Chef, but upgrading ruby on all of our services is not a quick task.

At some point you may be forced to do it. Maybe because of a bug in Ruby. Maybe because the performance improvements will be worth it.

The Ruby dev team creates new Rubies to support (like 2.4.0-preview1 right now) and drops support for older Rubies. I have no control over that.

Also, I don't even understand why you care. If you see the warning on desktops, you can set an environment variable. If the warning is occurring on the servers, it will be in the logs and won't affect functionality at all. (If it does - let me know).

All its internal dependencies could be resolved via gemspec (as all the other gems do) and there's no reason to bring ruby_dep and annoying us all the time, unless you want to force users to use this gem.

I don't use OSX. However, rb-fsevent is a dependency. I don't need it. Still it's more useful to include it for everyone (including Windows users) than not.

You can have a modified version of Listen on your private gem servers.

I'm not trying to prove that what you're saying doesn't make sense. I'm curious about your reasons, to know if I can fix the cause, and not just "the problem".

I simply don't understand why adding an environment variable is such a big deal. I'm sorry to hear that it takes you time to update the servers. Still, the warning is harmless and there are lots of gems that report problems and warnings to STDERR. The memory usage isn't huge, etc.

Again, you can pick an earlier version of Listen and ask for backports of bugfixes to the 3.0.x branch.

Please stay constructive in your arguments. I've already removed other dependencies from Listen in the past (and put a lot of private time to do so), so I'm eager to remove ruby_dep if the benefits outweigh the costs.

Did anyone asked us if we are? NO.

How exactly would that work? How was I supposed to know you'd be annoyed?

The reason not to upgrade is our private decission and is off the scope of the discussion.

That's ok. If upgrading would solve the problem, and upgrading is too expensive and RubyDep saves me a lot of trouble now and in the future ...

... and setting an environment variable is too difficult for you ...

... then it seems like there's nothing reasonable I can do other than waste my time so you can be "less annoyed".

We don't need this.

As the only current active maintainer of Listen, I need this. I'm willing to compromise (given compelling reasons - like I have many times). If you're not, that's your choice.

So please give me a compelling technical reason to remove ruby_dep (or just the warnings in some other way) or the only option I'll have is to close this as "won't fix".

[heaven]

At some point you may be forced to do it. Maybe because of a bug in Ruby. Maybe because the performance improvements will be worth it.

So that we did a month ago, and don't have any reason to upgrade again.

rb-fsevent

This gem affects functionality of listen and allows to support more platforms, ruby_dep is different.

You are going off the topic all the way, commenting our business model, reasons to/not to upgrade, and asking to stay constructive, that's interesting. My constructive point of view was explained in the very first post (a bit emotional, though, sorry about that). The ruby dependency could (and should) be solved with gemspec (as it is already done), there's no any reason to bring ruby_dep, except of the wish to keep the world up to date, which unfortunately doesn't match the reality.

Ignoring the warning isn't too big deal, the big deal is that we get unnecessary things along with the listen gem, which is a must now. I don't like ignoring something, instead I'd prefer to uninstall the gem that I don't use.

I am also going to leave the thread since I have to explain the same thing again and again.

[e2]

The reason I'm asking all those questions is because ruby_dep serves more purposes than you are aware of.

"Removing the gem" has too many consequences - most of which you don't care about, but I do.

The gem is here to stay for now. You talk as if you're annoyed by the dependency itself rather than what it does.

The ruby dependency could (and should) be solved with gemspec (as it is already done)

That line is generated using RubyDep itself:

https://github.com/guard/listen/blob/master/listen.gemspec#L28

except of the wish to keep the world up to date, which unfortunately doesn't match the reality.

That's just the side-effect of not having enough time to support "all" Ruby versions while preparing for a major overhaul in Listen.

The REAL goal is to limit the set of Rubies where support is GUARANTEED.

The ruby dependency actually turned out to annoy a lot of people - mostly because their Travis builds stopped working on e.g. Ruby 1.8, etc.

It's better for builds to fail than for server startup to fail - but many people were still angry, because they preferred the opposite.

There are people out there that "hate" dependencies they don't need. But it's hard to make such dependencies optional. The version checking serves a few purposes. The fact that it's a separate gem is only a result of refactoring (with it's own problems).

If it wasn't the functionality would be part of Listen anyway.

the big deal is that we get unnecessary things along with the listen gem

I simply don't understand why that is important. Soon the Listen gem may be split into multiple smaller gems - will you be angry that "those are unnecessary" too?

What is the big deal? Do you have to digitally sign each gem? Do you have to deploy them manually to an internal gem server? Would integrating RubyDep functionality inside Listen itself help?

Or is it just the version checking warning you're annoyed with? (Now you say you aren't).

The reason the code is in RubyDep is because of the "single responsibility principle" and so it can be used for other projects.

So you shouldn't be concerned if Listen is one gem or 15.

For warnings I could implement something to let you do this in your Gemfile:

gem 'ruby_dep', require: 'ruby_dep/no_warnings'

Would that help?

[heaven]

Hi, if I had no unnecessary warnings I wouldn't bother about the number of gems. If the listen gem does need this gem I'd like it to use it but in a silent mode, just for its internal needs, because we didn't opt in for these warnings and ruby checks.

gem 'ruby_dep', require: 'ruby_dep/no_warnings'

A quiet mode would be great.

[e2]

Can you review this PR if it does what you need?

e2/ruby_dep#16

I'll close this issue. If there's something more you need (or something else), you can comment on the PR or open a new issue there (https://github.com/e2/ruby_dep/issues/new).

[e2]

FYI, Ruby 2.3.0 had a bug related to string literal handling (internal crash at MRI-level) - that actually prevented deployment with Puppet. The bug prevented me from switching to 2.3.0 until 2.3.1 was released with the fix. (I couldn't easily prevent the bug from being triggered).

Ruby releases don't happen often, so attempting to migrate as soon as they're available can help avoid lots of painful surprises.

RubyGems is also buggy and tied to a specific version of Ruby (unless you update). It's possible to blow up a deployment on an older Ruby. E.g. RubyGems 2.6.5 fixes symlink handling in gems. If you have custom gems using symlinks, they're likely botched if you created them with an older version of RubyGems.

I can set the requirement on a given RubyGems, but then people will complain - because they'll be forced to update RubyGems in their builds and deployments.

Even today I accidentally used RubyGems's --silent option accidentally, not knowing it's only available since 2.6.5.

And even RubyGems 2.6.6 fixes a bad bug where a previous version of RubyGems was installed during upgrade: rubygems/rubygems#1601

I really would've preferred to have been warned about issues like this. Can't make everyone happy, though.

[christhekeele]

I just updated my project to use ruby 2.3, and can't use guard.

Not complaining or expressing any opinion about whatever the argument is about here, just asking for some clarification since I don't fully follow the discussion:

If you think it is vulnerable then you can create a new minor release and require >= 2.3.1.

I'd get a lot of flack if I did that. A lot. That's why I have to mention vulnerabilities. It's much better for people to silence vulnerability warnings than for busy developers to spend lots of unpaid time supporting Ruby versions no one should actually be using.

And:

The bug prevented me from switching to 2.3.0 until 2.3.1 was released with the fix.

My understanding is that 2.3.1 is officially released and supported, and ruby_dep supports that version. My questions are:

• Is the conclusion of the discussion above that guard/listen won't be adding support for 2.3.1?
• If not, what can I do to help make that possible?

From my poor understanding all that needs to be done is bump ruby_dep, and change the .travis.yml to include 2.3.1 but not 2.3.0, and deal with any build failures. If that's something I can do for you, please assign an issue to me and I'll see what I can do.

[e2]

@christhekeele - everything above Ruby 2.2.5 should work fine (2.2.5, 2.3.0, 2.3.1 and soon JRuby 9.1.x.x).

If it doesn't open an new issue. It should work perfectly with no warnings if you're using 2.2.5 or 2.3.1. (And JRuby 9.0.5.0 should also work without a warning).

This issue is about just hiding the warnings in a different way (I've updated the title).

Meanwhile, I'm preparing a new release of ruby_dep to support JRuby 9.1.2.0 and fix this issue here.

Otherwise, everything is expected to work.

[e2]

@christhekeele -

I just updated my project to use ruby 2.3, and can't use guard.

That might be a different issue. Open a new issue with details. (If it's already reported, I'll link it).

[christhekeele]

Nope, you're totally right. My terminal where I was running guard started complaining about how listen only supports certain versions, but opening a new tab worked. For obvious reasons my guard tabs tend to be long-lived.

Mea culpa, thanks!

[MentalPower]

Can we make this the default for the listen gem? There's a real risk of it being removed from Ruby on Rails otherwise: rails/rails#26709 (comment)

[e2]

Reopening this.

The fix would be to set RubyDep logger to nil: e2/ruby_dep#26 or to have RubyDep use the Rails logger.

I'll fix this soon.

[wjordan]

ruby_dep was removed by 45802c5 which should resolve this issue.

[ColinDKelley]

Closing this issue since ruby_dep is no longer in use.