ruby/curses — pull request #4 by tiredpixel (2014-02-24 20:35:27+00:00)
Title: Make pre-2.1.0 installation a successful no-op.

@hsbt (and others), thank you for your response to https://github.com/ruby/curses/issues/1 . I had originally hoped that the workaround I was using (moving the curses dependency to be satisfied within an extension) would be sufficient; however, @ChrisArcand kindly brought to my attention that this did not work when attempting to execute the gem within the context of `bundle exec`, which appears to use the `gemspec` directly. This is a problem not just for me, but for others who likewise wish to be able to support multiple Ruby versions within their gems (https://github.com/sportngin/opsicle/issues/22).

Although it is true that the curses gem itself is not required pre-Ruby-2.1.0 since curses is present within ruby-core, having installation for these versions fail prevents the curses gem from being specified as a formal runtime dependency within the gemspec. I do not know of a sufficient workaround for such gems to be able to cover all cases, but even if such were known, I would be concerned about the prospect of curses-dependent multi-Ruby-version gems having to each include such workarounds.

Thus, I request that we instead make pre-Ruby-2.1.0 installation of the curses gem a no-op, perhaps using code such as is in this pull request. This would enable curses to be specified as a formal runtime gem dependency in curses-dependent projects, with `require 'curses'` using the ruby-core version pre-Ruby-2.1.0 and the gem version thereafter. Tests I have performed, kindly confirmed by @ChrisArcand and @anfleene (https://github.com/sportngin/opsicle/issues/22), appear to indicate that this would solve the issues encountered and likely prevent the need for any sort of inadequate workarounds downstream (https://github.com/tiredpixel/sidekiq-spy/commit/16ead977fa837966736b7dc50b3cfa6a3dd7d3c2).

Peace, tiredpixel

---

curses is part of ruby-core pre-2.1.0, so this gem is not required for such versions. Previously, installation failed on Ruby 1.9.3 (but was successful on Ruby 2.0.0). https://github.com/ruby/curses/issues/1

Subsequently, `required_ruby_version` was set in the `gemspec` to clarify that only 2.1.0 and later are supported. https://github.com/ruby/curses/commit/4e55ed5c82af33743570a9daa05ef0884a79c06a

But this still means that gems attempting to offer multi-version Ruby support fail, because of not being able to specifify `gem 'curses'` within the `gemspec`. Instead, use the referenced resolution within https://github.com/guard/listen/issues/83 as inspiration, and make pre-2.1.0 installation result in a no-op. In such a case, `require 'curses'` is expected to work as usual.