Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gempsec allows incompatible versions of ruby #559

Open
scpike opened this issue Aug 22, 2024 · 6 comments
Open

gempsec allows incompatible versions of ruby #559

scpike opened this issue Aug 22, 2024 · 6 comments

Comments

@scpike
Copy link

scpike commented Aug 22, 2024

ice_cube 0.17.0+ starts using the new "anonymous block argument" feature of Ruby 3.1+ (https://rubyreferences.github.io/rubychanges/3.1.html#anonymous-block-argument). This syntax is incompatible with Ruby 3.0 and below, but the gemspec allows installing ice_cube with any version of Ruby. It's used for example here.

If you are still on Ruby 2.7 and are trying to upgrade, 0.16.4 is the version that is dual-compatible with both ruby 2.7 and 3.0.

Feel free to close this issue, I just wanted to document this here for anyone else who runs into the same thing in the future.

@rellampec
Copy link

Lost support for ruby 2.x.x

Line of the error

/app/vendor/bundle/ruby/2.7.0/gems/ice_cube-0.17.0/lib/ice_cube/schedule.rb:163: syntax error, unexpected ')', expecting local variable or method (SyntaxError)
    def each_occurrence(&)
                         ^
/app/vendor/bundle/ruby/2.7.0/gems/ice_cube-0.17.0/lib/ice_cube/schedule.rb:164: syntax error, unexpected ')'
...rate_occurrences(start_time, &).to_a
...                              ^
/app/vendor/bundle/ruby/2.7.0/gems/ice_cube-0.17.0/lib/ice_cube/schedule.rb:502: syntax error, unexpected `end', expecting end-of-input

@pacso
Copy link
Collaborator

pacso commented Nov 6, 2024

Whilst we build and test for the current supported versions of Ruby (https://www.ruby-lang.org/en/downloads/branches/) we do not (currently) prevent use with other versions. If you feel this should be the case, we can update the gemspec to specify the supported versions of Ruby.

@scpike
Copy link
Author

scpike commented Nov 6, 2024

@pacso Since you can't retroactively update the gemspec for 0.17 I just wanted to report what I ran into here for anyone who is searching. I think it's pretty split in the community whether it's best practice for gemspecs to have strict upper bounds on their dependencies. You can cause more trouble than it's worth if you limit the bounds too much and then people are left waiting for you to release a patch before they can upgrade.

It could be helpful to users with old codebases to avoid using the anonymous block argument feature in library code since there are backwards compatible ways to work around it, and it's not improving performance (see the comment about it in the link I shared).

@pacso
Copy link
Collaborator

pacso commented Nov 6, 2024

Thanks @scpike. If you're keen to improve our backwards compatibility feel free to ping over a PR and I'll review it 👍🏻

@scpike
Copy link
Author

scpike commented Nov 6, 2024

I put up a PR at #562. I then realized it's identical to #561 except that I widened the set of ruby versions being tested against.

@scpike
Copy link
Author

scpike commented Nov 6, 2024

Just for a little more context here - I'm not suggesting that it's a good thing to stay on old versions of Ruby. This came up for me because my company upgrades Ruby/Rails apps, and we often deal with large projects that are pretty deep in a hole. We strongly prefer to do upgrades incrementally and in small pieces, so for example we'd much prefer to upgrade ice_cube and ruby independently, rather than coupling them together in the same PR. That's why I pointed out 0.16.4 above since it's a version of ice_cube that's dual-compatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants