search

celluloid / celluloid-io

UNMAINTAINED: See celluloid/celluloid#779 - Evented sockets for Celluloid actors
https://celluloid.io
MIT License
879 stars 93 forks source link

Not bundling with ruby < 2.2 #181

Closed HoneyryderChuck closed 7 years ago

HoneyryderChuck commented 7 years ago

I'm having this annoying error everytime I have to bundle with celluloid-io in ruby < 2.2, where nio4r 2.0.0 resolves and breaks because it dropped support for such rubies. I don't know exactly the reasons for nio4r 2.0.0 not supporting lower rubies (kwargs perhaps?), but this change should therefore be reflected in celluloid-io to avoid headaches (for now I'm resolving nio4r versions myself in the Gemfiles, but the problem surges in libraries depending on it).

A couple of suggestions:

tarcieri commented 7 years ago

Upgrade to the latest bundler and and ruby RUBY_VERSION to the top of your Gemfile. Or add your own constraints on the nio4r version.

Support for versions earlier than Ruby 2.2 were dropped following suit with Rails 5. Ruby 2.1 will most likely be declared EOL next month. I would suggest upgrading to a version of Ruby that isn't EOL.

HoneyryderChuck commented 7 years ago

My use case is a library which uses celluloid-io as a dependency, and is installed as a system gem (no gemfile). Upgrading can't be done without a Ruby version manager. And there is no rails 5.

Can't this be resolved on the gemspec level? Like "if Ruby greater than add this dep, otherwise had this dep." ?

tarcieri commented 7 years ago

If you have a recent Bundler and add ruby RUBY_VERSION to the top of your Gemfile, it should do it automatically.

You can also add transitive dependencies to your Gemfile, and specify version constraints on them.

This is going to become increasingly a problem so long as you use an EOL Ruby, FYI.

HoneyryderChuck commented 7 years ago

I've just described you a use-case where bundler isn't used. Yes, I know how to handle these things using a Gemfile, it's not about that.

FWIW I'm not asking you to keep supporting EOL'ed versions of ruby, I understand the maintenance burden, I'm just asking you not to abruptly "break the build" needlessly. I say needlessly, because I've been using in production (and developing against) celluloid-io 0.16-0.17 since at least ruby 2.0, and it "just works". Not asking for corner case fixes for EOL'ed rubies as well.

I'll also add that the readme states "support ruby 1.9.3 up to 2.3.1" (yes, if you use nio4r < 2). I'll also point that celluloid-io master is currently breaking in travis CI due to a "laxed" dependency of a gem (listen) which broke support for rubies < 2.2 in version 3. In their case, they "communicated" that support termination using semver, and the celluloid suite could just pick it up.

This is just a suggestion of a solution that could be added in celluloid: communicate support termination using versioning. I know, it's not 1.x yet so one can do whatever, but one could just release an 0.18 version terminating support to EOL'ed rubies. Would any of these (or the previous) suggestions be something we could agree on? I could PR smth if we could.

Again, I'd like to expose my use-case: customer deploys a VM (behind a proxy) with stock ruby 2.0, and tools are installed system-wide. Tools (mostly general-purpose scripts, some deamons) use an in-house library using celluloid-io to configure remote devices. Can't influence much the decision about ruby version manager or ruby upgrades. And no rails 5.

tarcieri commented 7 years ago

Your problem is fundamentally a dependency resolution problem, and it both has a solution and one bundler can find for you.

I'm sorry you're not using bundler, and I'm sorry you want to use EOL Rubies, and I am sorry I have not updated the README of every last project to remove the EOL Rubies (I am still systematically going through them to do this, but there are a lot of them and it takes time).

But fundamentally: this is not a problem with this gem (and hence why I closed the issue). This is a problem with your current deployment system failing to resolve a solution.

I will eventually get to Celluloid::IO and correct some of the problems you mentioned, but I may or may not change the dependency relationship between celluloid-io and nio4r.

I would strongly suggest getting off EOL'd Rubies and adopting bundler for your deployments.

HoneyryderChuck commented 7 years ago

About the rubies, again not my call, but correlating the ruby EOL policy with the versions shipped in linux distributions and the rate of upgrades, it's hard to keep up without a version manager. But I agree, my system problem.

I just wanted to expose my use case and provide arguments, discuss a possible agreement and offer my contribution. If you think it is an edge case (I agree, it is) not worthy of specific handling, I'll have to accept.