- Notifications
You must be signed in to change notification settings - Fork417
-
I'm migrating a very old Rails application to a new server (Ruby 1.8.7 & Rails 2.5). And I know it needs to be update and, in fact, we're doing that right now but it won't be ready for about 6 months. In the meantime the Ruby 2.5 requirement for concurrent-ruby is making it impossible to reinstall some of the gems I need. I'm using the same version numbers of the gems that are working on the old server. I thought the rubygems system was designed so that the gems would load their dependencies in such a way that everything was compatible down the stack. Why are the dependencies no longer installable? More importantly, how can I resolve this problem. I need a version of concurrent-ruby that works with Ruby 1.8.7. It must have existed back when because the dependent gems were installed and working but I can't find it. |
BetaWas this translation helpful?Give feedback.
All reactions
Replies: 2 comments
-
That's how it should work. It's possible that concurrent-ruby, as a transitive dependency, is being updated to a new version. Can you share what version of concurrent-ruby is in your original ....though now going all the way back in history, this project was never compatible < 1.9.2: 7735835#diff-6cb223342d2567b655c08e6a9e674b52ce92a74525a3daa515f8896e69da7d68 |
BetaWas this translation helpful?Give feedback.
All reactions
-
Rails 2.3 doesn't use Gemfile and Gemfile.lock. I'm installing each gemindividually with -v for the exact version my old server uses. Althoughthree of my gems use concurrent-ruby only one of them (Searchlogic) iscritical. Interestingly, concurrent-ruby does not appear in my gem list onthe old server. I have no idea how Searchlogic and the other two gems eveninstalled themselves without it (remember the version numbers are the sameas on the old server).Thanks for getting back to me. I already checked the old versions ofconcurrent-ruby and saw that they all depended on 1.9.2 or .3. I'm going tostart over with 1.9.3 and see how far I can get.Thanks againStan<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>Virus-free.www.avg.com<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> …On Tue, May 23, 2023 at 2:38 PM bensheldon ***@***.***> wrote: I thought the rubygems system was designed so that the gems would load their dependencies in such a way that everything was compatible down the stack. That's how it should work. It's possible that concurrent-ruby, as a transitive dependency, is being updated to a new version. Can you share what version of concurrent-ruby is in your original Gemfile.lock? If it's not listed in your Gemfile, locked to that version, it's possible that bundler will increase the version. ....though now going all the way back in history, this project was never compatible < 1.9.2:7735835 #diff-6cb223342d2567b655c08e6a9e674b52ce92a74525a3daa515f8896e69da7d68 <7735835#diff-6cb223342d2567b655c08e6a9e674b52ce92a74525a3daa515f8896e69da7d68> — Reply to this email directly, view it on GitHub <#995 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACXNDGIVTQEVHT5AHX3JGDXHT7ZBANCNFSM6AAAAAAYMGZOBE> . You are receiving this because you authored the thread.Message ID: <ruby-concurrency/concurrent-ruby/repo-discussions/995/comments/5981589@ github.com> |
BetaWas this translation helpful?Give feedback.