-
Notifications
You must be signed in to change notification settings - Fork 29
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
Avoiding "already initialized constant errors" with net/protocol #16
Comments
Attempting to use an updated net/imap as a separate dependency causes "already initalized constant errors": ```shell $ bundle exec rspec spec /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:66: warning: previous definition of ProtocRetryError was here /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:206: warning: previous definition of BUFSIZE was here /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:503: warning: previous definition of Socket was here ``` This happens because MRI already includes its own implementation of net/protocol, and this dependency causes a redefinition of the same file. Closes ruby#16
net/protocol and net/imap have been default gems since Ruby 3.0, so it may introduce problems to remove net-protocol from dependencies. @hsbt What do you think? |
@stanhu I'm interested in this is issue. Can you share steps to reproduce the warnings? |
@deivid-rodriguez The easiest way I've been able to reproduce it: git clone [email protected]:tpitale/mail_room.git
cd mail_room
echo 2.7.2 > .ruby_version # Choose your version
bundle install
bundle exec rspec spec/lib/mailbox_spec.rb |
Thanks, I'll have a look! |
The proper fix here in my opinion would be that the faraday-net_http gem would declare the This is the explanation of what's happening:
If I suggest that you proposed this update to |
As described in https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/, Ruby 3.0.0 promoted net-http from stdlib. Adding this as a dependency avoids "aleady initialized constant errors" if net-imap or some other gem is included. See ruby/net-imap#16 (comment) for more details.
As described in https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/, Ruby 3.0.0 promoted net-http and net-imap from stdlib. Adding net-http as a dependency avoids "already initialized constant errors" if net-imap or some other gem is included. See ruby/net-imap#16 (comment) for more details.
As described in https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/, Ruby 3.0.0 promoted net-http from stdlib. Adding this as a dependency avoids "already initialized constant errors" if net-imap or some other gem is included. See ruby/net-imap#16 (comment) for more details.
@deivid-rodriguez Thanks for that tip! That seems to work well. I've submitted lostisland/faraday-net_http#5 and tpitale/mail_room#123. |
As described in https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/, Ruby 3.0.0 promoted net-http from stdlib. Adding this as a dependency avoids "already initialized constant errors" if net-imap or some other gem is included. See ruby/net-imap#16 (comment) for more details.
One issue is that net-http requires Ruby 2.6, so older Rubies won't work with this |
It's not related dependencies of gemspec. |
Oh, I see, that's unfortunate. I guess you need to workaround this via |
As described in https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/, Ruby 3.0.0 promoted net-http and net-imap from stdlib. Adding net-http as a dependency avoids "already initialized constant errors" if net-imap and faraday are used. See ruby/net-imap#16 (comment) for more details.
Cointidentially I run into a similar instance of this issue myself today. To make things easier for gem authors and motivate them to add the dependency, I propose to release at least one gemified version of |
…ve warnings when running bunlde exec rspec [ruby/net-imap#16]
This avoids the "already initialized constant" errors that evidently result from faraday's dependencies requiring two different versions of net-protocol. For discussion see: ruby/net-imap#16 (comment)
explained and recommended at ruby/net-imap#16 (comment)
Hi @deivid-rodriguez, I'd like to chime in on the discussion since I've been asked multiple times to add I explained my understanding of the issue in this comment and why I believe it is a mistake to add these gems explicitly in gemspec. If faraday were to add For example, I'd expect issues like this to pop up if I did that. I'm not sure why some gems have started adding explicit dependencies to these gems, but it seems like letting Ruby figuring it out by itself (when to use the stdlib or the standard gem) is the best way to avoid this mix and match and support both Rubies older and newer than 3.0. I understand some people are affected by this issue because they use a gem that has added one of these dependencies to their gemspec, and I can see why it's annoying to now having to add more dependencies themselves. It would be great to discuss this and agree to a solution that could benefit everyone 🙏 |
Sorry I don't have a lot of time to look into this right now, but I can say something similar to this has been discussed in the upstream Ruby tracker, and there's no agreement. For example, https://bugs.ruby-lang.org/issues/16951. Note that I did propose ruby/net-http#19 after that message you mention to avoid this problem, but it didn't happen. Not sure about your specific situation and the range of rubies where issues would pop up vs the range of rubies that would benefit from it. If this would only cause problems on rubies that have reached EOL, and those problems are only warnings, then I do think it's worth prioritizing users of supported rubies. But you know best what makes more sense for your libraries, and of course you can chime in the core tracker and propose any solutions. As I said, I don't have a lot of time right now, sorry :( |
This is great context, thank you @deivid-rodriguez. |
No problem, sorry I can't help more right now, and I appreciate your conciousness and will to get to the bottom of things. |
This is very vague claim and might or might not be true. It very much depends on the context.
This is overstatement. Generally, there is nothing wrong in using gemified version of library in old Ruby. The |
Right, I'm still unclear about the issue with newer rubies. There's many moving parts so there could be some issue, I just don't know what it is right now. As I have pointed out in other places, adding explicit dependencies helps Bundler and RubyGems provide consistent results. And also helps users because the exact gem version is recorded in the lockfile just like any other dependency, so you get consistent results when using the dependency even if you switch rubies. |
ref: ruby/net-imap#16 (comment) Fixed specs, but now how does the CI go.
Due to us being on Ruby 2.7 and faraday-net_http not having a dependency on the `net-http` default gem (to maintain Ruby 2.5 compatibility) - see ruby/net-imap#16. Issue should go away on Ruby 3.
Thanks, @deivid-rodriguez, it works perfectly! |
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Add net-http to Gemfile as per: ruby/net-imap#16 (comment)
Cross posting a refinement of our similar comment on mikel/mail#1523 I've been pairing on this with a few folk at RubyRetreat AU 2024 in an attempt to get to the bottom of this. Thanks crew! @KJTsanaktsidis @moxvallix @layerssss The impact of this issue extends from those relying on this gem to the mail gem and is likley affecting most apps attempting to upgrade from Rails 5.1 to Rails 6.x on their journey through a rails upgrade path. Rails relies on this mail gem which in turn is relying on net-http, net-imap, net-smtp which is where the conflicts lie. net-http, net-imap, net-smtp are only gemified from ruby 3.0 BUT all versions of the net-http gem (v0.1.0 up to latest 0.4.1) list an incorrect minimum support ruby as being >= 2.6.0, but it should be listed as >=3.0 A few compounding issues:
WORKAROUND PROCESS: |
/usr/local/lib/ruby/2.7.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError ruby/net-imap#16 (comment)
If I have a gem that depends on
net/imap
v0.2.1, I see that it conflicts with the Ruby interpreter's version:$ bundle exec rspec spec /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:66: warning: previous definition of ProtocRetryError was here /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:206: warning: previous definition of BUFSIZE was here /home/travis/.rvm/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket /home/travis/.rvm/gems/ruby-2.6.6/gems/net-protocol-0.1.0/lib/net/protocol.rb:503: warning: previous definition of Socket was here
Is there a way this updated version of the gem can be used as a separate dependency without generating these warnings? https://stackoverflow.com/a/9117903/1992201 has some suggestions, but these still seem like hacks. Does it make sense to remove
net/protocol
as a hard dependency? MRI appears to have an exact copy ofprotocol.rb
.The text was updated successfully, but these errors were encountered: