date dependency requires native compilation

[nevans]

There is a major issue with date: it requires native compilation. My server does not have a compiler installed for security reasons and I cannot install the latest version of net-imap now.

I install Ruby from distro packages and then a set of pure Ruby gems but net-imap is no longer pure. ☹️

Originally posted by @mperham in #66 (comment)

I've been deploying everything in containers for a while now, so I forget about these pain points. It's a common pattern for production Dockerfiles to either uninstall compilers or copy compiled libs over from another image layer.

Unless you are deploying to ruby 2.4 and older, some version of the date gem should be installed already... so if you are willing and able to simply pin the version that matches your distro ruby installation, that should work, I think.

Another option might be to create native gem files, maybe scripted with docker or rake-compiler or maybe rake-compiler-dock, upload them to S3, and configure the server with an S3 gem source.

I wonder if ruby/date would consider a PR for publishing pre-compiled native gems?

And, of course, you could fork net-imap and install from your fork. Or we could drop the explicit dependency. ☹️

@hsbt Any thoughts?

[mperham]

The issue here is that mail 2.8 now requires net-imap and almost every Ruby app that sends email via SMTP is now pulling in net-imap even though most of them do not use or need IMAP. Anyone wanting a pure Ruby environment will need to lock to mail 2.7.1.

I really wish Rubygems had optional dependencies so I could disable this type of unnecessary dependency.

[nevans]

@mperham instead of locking to mail 2.7.1, you could lock the date gem to

Gem::Specification.find{_1.name == "date" && _1.default_gem?}.version

You could even add that to the Gemfile (although you would still need a different lockfile for each version of ruby). Or you could add bundle add date --version $(ruby -e 'Gem::Specification.find...') to your deploy scripts?

Or you could lock net-imap to 0.3.1. If you don't even care about net-imap, then that might be the quickest, simplest answer!

Obviously, manually managing gem versions like this is a pain.

[nevans]

@mperham, I was about to start a discussion over at https://github.com/rubygems/rubygems, but then I wondered if the feature I wanted wasn't already supported. So I read through the bundler docs and found an existing option which might work for you, bundle install --prefer-local:

       --prefer-local
              Force  using  locally installed gems, or gems already present in
              Rubygems´ cache or in  vendor/cache,  when  resolving,  even  if
              newer  versions  are available remotely. Only attempt to connect
              to rubygems.org for gems that are not present locally.

It's not exactly what I was looking for, but it might be a better solution than the others I suggested?

In addition to your "optional dependencies" suggestion, I have a few other ideas for potential bundler features that maybe would help. i.e. bundle cache --include-platform-extensions or bundle install --prefer-system or bundle add --source system. But I'll save any deeper discussion of bundler feature requests for the rubygems repository. 😉

[mperham]

I think explicitly locking versions with a comment is superior to using Bundler in a non-default mode. The KISS principle. 99% of Ruby developers, including myself, have no idea what the side effects of that switch are.

[nevans]

I think explicitly locking versions with a comment is superior to using Bundler in a non-default mode. The KISS principle. 99% of Ruby developers, including myself, have no idea what the side effects of that switch are.

I know what I want and expect the effects to be, but I've never actually used it so that also puts me in the 99% who have no idea! 😉

[hsbt]

I wonder if ruby/date would consider a PR for publishing pre-compiled native gems?

I can release it. But pre-compiled gems need many of maintenance resources. I'm negative to do it.

Or we could drop the explicit dependency. ☹️

It's the short-term solution. Because date gem(= library on ruby/ruby repository) has no maintainer now. So, I will extract date from ruby/ruby repository. After that, net-imap will break the missing dependency of date library.

We don't have to extract embedded Time library to default or bundled gem. Can we rewrite lib/net/imap/data_encoding.rb with Time class?