Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):
On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch <vondr...@redhat.com> wrote:Working on Puma 6.0, I have hit this [1] issue rebuilding rubygem-shoulda-matchers: ~~~ 1) shoulda-matchers integrates with Rails in a project that uses Spring Failure/Error: run_rake_tasks!('db:drop', 'db:create', 'db:migrate') RuntimeError: Command "BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\" bundle _2.5.3_ exec rake db:drop db:create db:migrate --trace" exited with status 1. Output: ---START---------------------------------------------------------------- bundler: failed to load command: rake (/usr/bin/rake) /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in `raise_not_found!': Could not find gem 'puma (~> 5.0)' in locally installed gems. (Bundler::GemNotFound) The source contains the following gems matching 'puma': * puma-6.4.2 from /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in `block in prepare_dependencies' from /usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in `each' ... snip ... ~~~ The thing is that RoR 7.0 hardcodes `"puma", "~> 5.0"` dependency. Now there are two options: 1) Relax the dependency in rubygem-should-matchers. 2) Relax the dependency in RoR in a similar way to RoR 7.1 [3] (and maybe [4], but I have not hit any issue in anycable 🤷) I hope to upgrade to 7.1 soon anyways. I think it's a good place to fix.
👍
While the former is low impact, I lean towards the latter, despite
changing the generated application might put some users into risk.
Thoughts?
No severe risk expected; just the test fix [4] you've found. I'll
ideally re-run all RoR test suites which use Puma :). If you haven't
already....
I have used MPB, which should rebuild the first level dependencies. I think this could be enough.
They've mentioned it (probably) breaks capybara: https://github.com/puma/puma/blob/master/6.0-Upgrade.md#upgrade
It does break older version of capybara, but the update you have pushed like two days ago seems to be fine.
Some testing (with the rebuild above) might be worth the time. Do you have some PR yet, or should I use your COPR build[5]?[5] https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885218/
No PR, the Copr build should be fine (as fine and stable Puma can be 🙈). But I'd like to land this before today EOD to get rid of this. So please hurry 😉
Vít
Thanks for all the work!
Regards,
Pavel
Vít
[1]:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/
[2]:
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172
[3]:
https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7
[4]: https://github.com/rails/rails/pull/46106
--
_______________________________________________
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org
To unsubscribe send an email toruby-sig-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
