-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add support for Rails 6 #3236
Add support for Rails 6 #3236
Conversation
On @spaghetticode's advice, I have removed the commit that converted |
@aldesantis makes sense, are you going to open a new PR with the |
@kennyadsl yes, probably after we merge this one. |
@aldesantis isn't better to start using |
@kennyadsl definitely, what I meant was that instead of opening a PR now and then having to constantly keep it up to date with |
@aldesantis Can you expand on rspec 3.8 and rails 6 support? I've not seen any issues on any of my rails 6 projects. I'm not saying there aren't issues, but I am curious what those could be that would require solidus to await rspec 4 before upgrading to Rails 6 |
We're almost there guys, we're just waiting for RSpec 4 at this point! |
@aldesantis you can use |
core/solidus_core.gemspec
Outdated
s.add_dependency 'awesome_nested_set', '~> 3.0', '>= 3.0.1' | ||
s.add_dependency 'cancancan', '~> 2.2' | ||
s.add_dependency 'awesome_nested_set', '~> 3.2', '>= 3.0.1' | ||
s.add_dependency 'cancancan', '~> 3.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to use 3 and above. It also works with ['>= 2.1', '< 4.0']
We want to keep our dependencies always as low as possible to avoid conflicts with other gems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tvdeyen I tried with >= 2.1, < 4.0, but I get tons of these:
111) Taxonomies show should display existing taxonomies
Failure/Error: @search = Spree::Order.accessible_by(current_ability, :index).ransack(params[:q])
CanCan::Error:
The accessible_by call cannot be used with a block ‘can’ definition.The SQL cannot be determined for :index Spree::Order
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. This does not seem to be Rails 6 related to me. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need #3174 as well? Maybe loading that code conditionally if Rails >= 6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented on #3174 that we should try to allow 2 as well. It should work as it only removes lots of quirks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even with the patch from #3174, I keep seeing lots of test failures when using CanCanCan 2. I think an upgrade to 3 is required, but again, let me know if you find a way to make the suite pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see some of these errors. I ask myself what a Rails update should change in terms of these errors from cancancan. The issue is that we try to use the same ability rule for scopes as well for single records. Then cancancan is not able to generate the correct sql for the scope. Very interesting.
I really would like to not raise a commonly used dependency like cancancan if we find a way to not need it. I know this might be disappointing and we all want to land Rails 6 support, but we also have responsibility for not breaking extensions and stores that might use dependencies that are not supporting cancancan 3 yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aldesantis, this PR is great! I left some preliminary comments, let me know your thoughts!
awesome_nested_set 3.2.0 is the first release to provide Rails 6 compatibility.
@kennyadsl I have rebased with more granular and detailed commits. Let me know what you think! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the commit message for the cancancan bump you say that 3.0 is the first version that supports Rails 6. From their gemspec this does not seem to be true. 2.x should also work. Do you have evidence for that claim? If it’s not possible without that bump, fine. But I would like us to try without the bump.
I also think we do not need to wait for rspec 4 as well.
core/solidus_core.gemspec
Outdated
s.add_dependency 'awesome_nested_set', '~> 3.0', '>= 3.0.1' | ||
s.add_dependency 'cancancan', '~> 2.2' | ||
s.add_dependency 'awesome_nested_set', '~> 3.2', '>= 3.0.1' | ||
s.add_dependency 'cancancan', '~> 3.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see some of these errors. I ask myself what a Rails update should change in terms of these errors from cancancan. The issue is that we try to use the same ability rule for scopes as well for single records. Then cancancan is not able to generate the correct sql for the scope. Very interesting.
I really would like to not raise a commonly used dependency like cancancan if we find a way to not need it. I know this might be disappointing and we all want to land Rails 6 support, but we also have responsibility for not breaking extensions and stores that might use dependencies that are not supporting cancancan 3 yet.
@tvdeyen you were right on CanCanCan, I went with By the way, should we use |
@aldesantis No worries. You did an amazing job!
Yes, sorry, I just copyied it over from another project ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job 🍨
Lets merge this and let people try master
with Rails 6. Release the new version after everything stabilized.
Bumped CanCanCan's lower bound to 2.2! |
I have also made Rails 6 the default in CircleCI and in the Gemfile, as per @kennyadsl's request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aldesantis, this work is amazing. When we'll merge this, I'll try to release a 2.10.0.rc or alpha version so we can start having some store try Solidus with Rails 6 easily!
Are we waiting for a full release of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't wait to see Solidus on Rails 6.0, thank you @aldesantis 🎉 💯 💥 🚀 ❤️
CanCanCan 3.0.0 is the first release with Rails 6 compatibility.
state_machines-activerecord used to have a level constraint on ActiveRecord that prevented us from using it with Rails 6. This was removed[1] in 0.6.0. [1]: state-machines/state_machines-activerecord@e7857a6
Zeitwerk expects file paths to match module names exactly, so we need to use #prepend for files that extend existing modules.
In Rails 6, ActiveRecord will always cast numbers to decimals when comparing them against a decimal column.
In Rails 6, ActiveSupport notifiers use two separate instance variables for string subscribers and object subscribers, so we need to use different setup/teardown logic for the test.
The changes to the CI configuration are needed because teaspoon_env is now[1] searched starting from Rails.root when Rails is available, which breaks our test suite because Rails.root is spec/dummy, while teaspoon_env.rb is in spec. The monkey-patch was removed because Teaspoon now supports passing options to Selenium[2]. [1]: jejacks0n/teaspoon@5b912da [2]: jejacks0n/teaspoon#537
🎉 🍾 💯 |
Description
Adds Rails 6 support. 🍾
Progress:
Before we can merge this, the following needs to be addressed:
secret_key_base
instead ofsecret_token
(see #160).Checklist: