Skip to content

Add former default gems as a dependency for Ruby 3.1 compatibility#1439

Closed
casperisfine wants to merge 2 commits intomikel:masterfrom
Shopify:net-smtp-dependency
Closed

Add former default gems as a dependency for Ruby 3.1 compatibility#1439
casperisfine wants to merge 2 commits intomikel:masterfrom
Shopify:net-smtp-dependency

Conversation

@casperisfine
Copy link

@casperisfine
Copy link
Author

Actually this cause double loading warnings for ruby 3.0 and older. I'm not too sure yet how best to fix this.

@casperisfine casperisfine changed the title Add net-smtp as a dependency for Ruby 3.1 compatibility Add former default gems as a dependency for Ruby 3.1 compatibility May 28, 2021
@casperisfine
Copy link
Author

David Rodríguez, bundler's maintainer is looking at the issue, I'll keep an eye and report back here when there's a solution: https://bugs.ruby-lang.org/issues/17873#note-18

@casperisfine
Copy link
Author

So the double loading issue was fixed in rubygems/bundler, we can probably merge this now.

tagliala added a commit to enriclluelles/route_translator that referenced this pull request Sep 12, 2021
tagliala added a commit to enriclluelles/route_translator that referenced this pull request Sep 12, 2021
net-smtp has been removed from default gems in Ruby 3.1, but it is used
by the `mail` gem.

Remove when mikel/mail#1439 is fixed
dillonwelch added a commit to devise-security/devise-security that referenced this pull request Oct 11, 2021
See the following:
* rails/rails#42366
* mikel/mail#1439
* https://bugs.ruby-lang.org/issues/17873

In essence, the net/smtp gem config was changed in ruby 3.1
and the mail gem needs to merge in their fix.
@casperisfine
Copy link
Author

Any news here?

s.add_dependency('mini_mime', '>= 0.1.1')
s.add_dependency('net-smtp')
s.add_dependency('net-imap')
s.add_dependency('net-pop')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these gems no-op on older Rubies (1.8, 1.9, etc)?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These gems yes, however they themselves have digest as dependency which is causing some doable loading problem:

/Users/byroot/.gem/ruby/2.7.2/gems/digest-3.0.0/lib/digest.rb:6: warning: already initialized constant Digest::REQUIRE_MUTEX
/opt/rubies/2.7.2/lib/ruby/2.7.0/digest.rb:6: warning: previous definition of REQUIRE_MUTEX was here
....

I already submitted the fix in bundler ruby/rubygems#4989, hopefully it should be fixed soon. I totally understand if you want to wait for bundler to fix this first.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is already fixed @jeremy @casperisfine. Can we release this?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to wrap these in an if statement that is only true for Ruby 3.1+?

Copy link
Contributor

@eregon eregon Jan 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem here is those gems can't be installed on older versions, @casperisfine's reply only shows part of the issue.

For example on 2.0.0:

$ gem i net-smtp            
Fetching: timeout-0.2.0.gem (100%)
Successfully installed timeout-0.2.0
Fetching: io-wait-0.2.1.gem (100%)
ERROR:  Error installing net-smtp:
	io-wait requires Ruby version >= 2.6.0.

$ gem i net-imap
ERROR:  Error installing net-imap:
	io-wait requires Ruby version >= 2.6.0.

$ gem i net-pop 
ERROR:  Error installing net-pop:
	io-wait requires Ruby version >= 2.6.0.

Also #1439 (comment)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nertzy I am pretty sure that an if statement in a .gemspec ends up getting evaluated at gem release time, and trying to condition on ruby version would end up being on what ruby version is running in the environment doing the gem release, and then fixed in the release.

My understanding is you can't actually do dynamic conditions based on the running environment in a gemspec like that.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally those gems ('net-smtp', 'net-imap' and 'net-pop') would all NOOP when installed on an older unsupported Ruby. That would just solve it for everyone.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm still trying to find solutions upstream, but ultimately would you be open to drop pre 2.5 support to get this moved forward now?

Copy link
Contributor

@eregon eregon Feb 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For context, CRuby devs don't seem generally happy to need to explicitly support (even as noop) such old and EOL Ruby versions based on recent discussions, which brings the age-old question: do gems depending on net-* and specifically mail still need to support Ruby <= 2.5 today?

Copy link
Contributor

@simi simi Feb 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can still go this way as well.

#1439 (comment)

Bump minor (or major) version and we can still maintain releases compat with <= 2.5 if needed in "legacy" branch.

Btw. I'm happy to help with anything moving this forward.

@lewispb lewispb mentioned this pull request Nov 9, 2021
@lewispb
Copy link
Contributor

lewispb commented Nov 11, 2021

Could we merge master and add Ruby 3.1 to the GitHub Actions matrix?

@casperisfine
Copy link
Author

Hum:

net-imap was resolved to 0.2.2, which depends on
        Ruby (>= 2.5.0)

That's a problem, not sure how we can possibly handle this.

@eregon
Copy link
Contributor

eregon commented Nov 12, 2021

If they noop (#1439 (comment)), maybe the required_ruby_version should be lower?

@casperisfine
Copy link
Author

If they noop

What do you mean?

@casperisfine
Copy link
Author

Ah nevermind, seems like I didn't properly understand @jeremy's question. They definitely don't noop.

So I don't see how we can support both 3.1 and 2.4

@eregon
Copy link
Contributor

eregon commented Nov 12, 2021

A somewhat crazy idea:
Create a new gem, e.g., mail-deps and make two releases:

  • one release with required_ruby_version < 3.1, and no deps
  • one release with required_ruby_version >= 3.1, and those 3 deps

Alternatively maybe those 3 gems should really have "empty/noop/using stdlib" releases with required_ruby_version < 2.5, so there is no need to redo something similar manually on top.

@eregon
Copy link
Contributor

eregon commented Jan 9, 2022

@pirj That does not work, RubyGems has a single gemspec for a given gem release, it's not evaluated every time bur rather serialized when building a gem.
Also see #1439 (comment)
The only case it might work is with bundler path:/git: but that's obviously just a subset of cases and seens no better than the workaround in #1439 (comment).

@mperham
Copy link
Contributor

mperham commented Jan 10, 2022

Does Ruby core know this is a problem? Is there a redmine ticket? They've been very good about compatibility IME and making the gems no-op on older MRI versions seems like a great idea.

mperham added a commit to sidekiq/sidekiq that referenced this pull request Jan 10, 2022
We need to remove Ruby 2.5 because the new net-smtp gem
is required for the mail gem on Ruby 3.1 but it does
not work on <=2.5.

mikel/mail#1439

Also remove an anon struct test which now breaks with
safe YAML loading on 3.1.
@casperisfine
Copy link
Author

Is there a redmine ticket?

The closest would be https://bugs.ruby-lang.org/issues/17873, but default gems have their own maintainers, and I think it ultimately fall onto them.

So we should open issues in the three repos:

@eregon
Copy link
Contributor

eregon commented Jan 10, 2022

Also io-wait since that's what fails currently: #1439 (comment)

@casperisfine
Copy link
Author

Indeed. I'll look into it tomorrow unless someone beats me to it.

@jeremy jeremy assigned eregon and unassigned eregon Jan 11, 2022
casperisfine pushed a commit to casperisfine/io-wait that referenced this pull request Jan 11, 2022
Ref: mikel/mail#1439

Some gems depend on io-wait, but still support older rubies,
so they have to chose between droping support or not listing io-wait.

But io-wait could act a a noop on older rubies.
@casperisfine
Copy link
Author

io-wait PR: ruby/io-wait#9

casperisfine pushed a commit to casperisfine/io-wait that referenced this pull request Jan 11, 2022
Ref: mikel/mail#1439

Some gems depend on io-wait, but still support older rubies,
so they have to chose between droping support or not listing io-wait.

But io-wait could act a a noop on older rubies.
casperisfine pushed a commit to casperisfine/io-wait that referenced this pull request Jan 11, 2022
Ref: mikel/mail#1439

Some gems depend on io-wait, but still support older rubies,
so they have to chose between droping support or not listing io-wait.

But io-wait could act a a noop on older rubies.
casperisfine pushed a commit to casperisfine/io-wait that referenced this pull request Jan 12, 2022
Ref: mikel/mail#1439

Some gems depend on io-wait, but still support older rubies,
so they have to chose between droping support or not listing io-wait.

But io-wait could act a a noop on older rubies.
casperisfine pushed a commit to casperisfine/io-wait that referenced this pull request Jan 12, 2022
Ref: mikel/mail#1439

Some gems depend on io-wait, but still support older rubies,
so they have to chose between droping support or not listing io-wait.

But io-wait could act a a noop on older rubies.
tvdeyen added a commit to tvdeyen/alchemy_cms that referenced this pull request Jan 16, 2022
@deivid-rodriguez
Copy link
Contributor

I think @simi's suggestion at #1439 (comment) is the best way to go. In order to reduce maintainers' burden to implement that solution, I created #1472, including the changes being proposed here.

@deivid-rodriguez
Copy link
Contributor

My PR includes a lot of cleanups of old Ruby 1.8 compatibility code that can be now removed. It can be argued that reviewing those changes actually increases maintainers' burden 😅. If that's the case, I'm super happy to remove those cleanups from my PR.

@mikel
Copy link
Owner

mikel commented Apr 19, 2022

Closing this in favour of #1472

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.