can't compile gems for migration

[shoresh]

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.

[bensheldon]

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

[shoresh]

Rails 2.3 doesn't use Gemfile and Gemfile.lock. I'm installing each gem individually with -v for the exact version my old server uses. Although three of my gems use concurrent-ruby only one of them (Searchlogic) is critical. Interestingly, concurrent-ruby does not appear in my gem list on the old server. I have no idea how Searchlogic and the other two gems even installed themselves without it (remember the version numbers are the same as on the old server). Thanks for getting back to me. I already checked the old versions of concurrent-ruby and saw that they all depended on 1.9.2 or .3. I'm going to start over with 1.9.3 and see how far I can get. Thanks again Stan <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>