add logger as dependency for ruby 3.5 support

[noraj]

fix #203

[alexdalitz]

❤️

[keithrbennett]

I did some research and got mixed results whether or not adding this dependency unconditionally was a good idea. Some said it should only be added where needed, with a guard to permit adding it only in certain versions. Would it be better to add such a guard ,e.g. the code below?:

  if Gem::Version.new(RUBY_VERSION) >= Gem::Version.new('3.4.0') # or other version number
    s.add_runtime_dependency 'logger', '~> 1.6.5' 
  end

(The Gem::Version approach was recommended at https://greena13.github.io/blog/2020/12/19/writing-ruby-gems-for-different-versions-of-ruby-and-rails/.)

[noraj]

Adding the dependency unconditionally could restrain the range of Ruby version supported. However, now requiring it before 3.4.0, means you'd have a different version of logger depending on the major version of ruby used (3.1, 3.2, 3.3) so it could be challenging for consistency.

Also, isn't it the kind of stuff you should put in your Gemfile rather than in the gemspec? If I remember correctly, having conditional requirement is challenging because it results in different lockfile depending on the Ruby version used to generated it (also there isn't a Gemfile.lock published for this project, or if there had one the CI could remove it before bundle install).

Idk. I remember I tried once to play with conditional dependency requirements in Gemfile/gempsec, and spent hours without finding a configuration that wasn't and headache to manage.

[noraj]

Isn't there something like You can’t use conditionals on gemspec because gemspec is serialized into YAML so you have to put it in Gemfile?

[noraj]

To be state of the art in term of dependency requirements, I would:

• Commit the Gemfile.lock

This is why the Gemfile.lock should be committed with version control, and shared between development and production deployments of the Ruby application. cf. source

• Not put any add_development_dependency in the Gemspec

Because else there are listed on Rubygems when you publish you gem.

And bundle install installs all dependencies (runtime and dev) by default so anyone end-up install dev dependencies that are useless for runtime if they don't provide the flag or env. var. to not install them.

• Specify the same runtime dependencies in the Gemfile as in the Gemspec.
• Add the dev dependencies in the Gemfile and tag them with proper grouping so they can be excluded for example on CI etc.

For example

Gemspec with only runtime dependencies
https://github.com/noraj/unisec/blob/master/unisec.gemspec

Gemfile with runtime and dev dependencies that also specify the Gemspec and precise grouping:
https://github.com/noraj/unisec/blob/master/Gemfile

Gemfile.lock published…:
https://github.com/noraj/unisec/blob/master/Gemfile.lock

…that was generated using the same version of Ruby as mentioned in .tool-versions which is the latest version supported by s.required_ruby_version = ['>= 3.1.0', '< 4.0'] in the Gemspec.
https://github.com/noraj/unisec/blob/master/.tool-versions

Proper grouping in the Gemfile allowing bundle to exclude useless groups like documentation in the CI:
https://github.com/noraj/unisec/blob/4f3637ddc92c4582318e1cbc78df67eb816a6789/.github/workflows/ruby.yml#L24

No dev dependencies in the Gemspec so they are no listed on Rubygems so people doing gem install unisec won't install them by default. Only people git cloning the github repo that performs bundle install that will actually dev on the project.

I think that would be the best and without conditional requirement of dependencies.

[keithrbennett]

Though this article is admittedly ancient (2010), Yehuda Katz ***@***.***) suggests at https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ : "When developing a gem, use the gemspec method in your Gemfile to avoid duplication. In general, a gem's Gemfile should contain the Rubygems source and a single gemspec line. Do not check your Gemfile.lock into version control..." There does seem to be some controversy surrounding checking the Gemfile.lock file of a gem into source control, but my feeling is that a dependency should not dictate to an app which version to use, when the dependency is something as commonly used across other dependencies and the app itself as `logger` is. Here is my conversation with Perplexity AI about it; its first response managed to look at the wrong PR even though I specified the URL (!) but subsequent responses make more sense: https://www.perplexity.ai/search/read-the-conversation-at-https-_KDFws65RKScBNBDKTGNpQ @wycats Is your take on this still the same as before?

…

------------------------------

In dnsruby.gemspec <#204 (comment)>: > @@ -48,5 +48,6 @@ DNSSEC NSEC3 support.' end s.add_runtime_dependency 'base64', '~> 0.2.0' + s.add_runtime_dependency 'logger', '~> 1.6.5' To be state of the art in term of dependency requirements, I would: - Commit the Gemfile.lock This is why the Gemfile.lock should be committed with version control, and shared between development and production deployments of the Ruby application. cf. source <https://greena13.github.io/blog/2020/12/19/writing-ruby-gems-for-different-versions-of-ruby-and-rails/> - Not put any add_development_dependency in the Gemspec Because else there are listed on Rubygems when you publish you gem. image.png (view on web) <https://github.com/user-attachments/assets/a2084736-378c-49db-b763-57296123956f> And bundle install installs all dependencies (runtime and dev) by default so anyone end-up install dev dependencies that are useless for runtime if they don't provide the flag or env. var. to not install them. - Specify the same runtime dependencies in the Gemfile as in the Gemspec. - Add the dev dependencies in the Gemfile and tag them with proper grouping so they can be excluded for example on CI etc. For example Gemspec with only runtime dependencies https://github.com/noraj/unisec/blob/master/unisec.gemspec Gemfile with runtime and dev dependencies that also specify the Gemspec and precise grouping: https://github.com/noraj/unisec/blob/master/Gemfile Gemfile.lock published…: https://github.com/noraj/unisec/blob/master/Gemfile.lock …that was generated using the same version of Ruby as mentioned in .tool-versions which is the latest version supported by s.required_ruby_version = ['>= 3.1.0', '< 4.0'] in the Gemspec. https://github.com/noraj/unisec/blob/master/.tool-versions Proper grouping in the Gemfile allowing bundle to exclude useless groups like documentation in the CI: https://github.com/noraj/unisec/blob/4f3637ddc92c4582318e1cbc78df67eb816a6789/.github/workflows/ruby.yml#L24 No dev dependencies in the Gemspec so they are no listed on Rubygems so people doing gem install unisec won't install them by default. Only people git cloning the github repo that performs bundle install that will actually dev on the project. image.png (view on web) <https://github.com/user-attachments/assets/1aa56d9c-c4ae-471d-a132-0cf7a5bd0f52> I think that would be the best and without conditional requirement of dependencies. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAG56XRXUPOLALQTGK3V6L2NESDZAVCNFSM6AAAAABV46NXNWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKOBRHE4DSOJWGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[noraj]

We could find articles defending any position.

There does seem to be some controversy surrounding checking the
Gemfile.lock file of a gem into source control

I think that's important to have reproducible builds. Or when the project is unmaintained for a moment compatibility with a newer version could break, the lock file ensures we at least have a configuration where it works.

my feeling is that a dependency should not dictate to an app which version to use,

I'm open about that, I don't really have arguments against or for it.

when the dependency is something as commonly used across other dependencies and the app itself as logger is.

The version requirements on logger could may be loosened. If someone is willing to test different versions of logger to move to something like s.add_runtime_dependency 'logger', '>= 1.5.0' accepting older versions.

It's difficult to know what the oldest version of Ruby should be targeted.

• s.required_ruby_version is not provided in dnsruby.gemspec
• .github/workflows/ci.yml tests only on Ruby 3.1-3.3 (3.4 is missing by the way)
• no .rubocop.yml including a TargetRubyVersion is provided is provided in git

The easiest move would be to support only Ruby supported versions (https://www.ruby-lang.org/en/downloads/branches/) so 3.1-3.4. And so supporting:

• logger 1.5.0 for Ruby 3.1.0 (https://docs.ruby-lang.org/en/3.1/NEWS_md.html)
• logger 1.5.3 for Ruby 3.2.0 (https://docs.ruby-lang.org/en/3.2/NEWS_md.html)
• logger 1.6.0 for Ruby 3.3.0 (https://docs.ruby-lang.org/en/3.3/NEWS_md.html)
• logger 1.6.4 for Ruby 3.4.0 (https://docs.ruby-lang.org/en/3.4/NEWS_md.html)

[noraj]

Here is my conversation with Perplexity AI

I don't trust AI answers as there is no intelligence behind it. That's just language parsing and statistics on bit datasets. So the IA must summarize what it "learned" from StackExchange or some blogs.

However, Shopify is an enterprise greatly proficient in Ruby (https://railsatscale.com/) and contributing a lot to the community, then often innovate and contribute to Ruby core. So it should be interesting to see what convention they apply on their projects: https://github.com/orgs/Shopify/repositories?q=mirror%3Afalse+fork%3Afalse+archived%3Afalse+language%3ARuby.

We can see they:

• commit Gemfile.lock
• declare runtime deps only in Gemspec (no double declaration like me)
• declare dev deps only in Gemfile
• always declare required_ruby_version in Gemspec
• they sometimes use conditional dependency based on version in the Gemfile: https://github.com/search?q=org%3AShopify+RUBY_VERSION+path%3AGemfile&type=code
• but never conditional dependency based on version in the gemspec https://github.com/search?q=org%3AShopify+%22RUBY_VERSION%22+path%3A*.gemspec&type=code&p=1
• etc.

[keithrbennett]

On Jan 31, 2025, at 3:16 AM, Alexandre ZANNI ***@***.***> wrote: Here is my conversation with Perplexity AI I don't trust AI answers as there is no intelligence behind it. That's just language parsing and statistics on bit datasets. So the IA must summarize what it "learned" from StackExchange or some blogs.

I agree that one cannot always trust AI responses, but as you say, it can learn from web resources and is very good at summarizing and expressing. So given the caveat that it requires an appropriate amount of verification, it can be useful, and has hugely accelerated my research and learning.

However, Shopify is an enterprise greatly proficient in Ruby (https://railsatscale.com/) and contributing a lot to the community, then often innovate and contribute to Ruby core. So it should be interesting to see what convention they apply on their projects: https://github.com/orgs/Shopify/repositories?q=mirror%3Afalse+fork%3Afalse+archived%3Afalse+language%3ARuby. We can see they: commit Gemfile.lock declare runtime deps only in Gemspec (no double declaration like me) declare dev deps only in Gemfile always declare required_ruby_version in Gemspec they sometimes use conditional dependency based on version in the Gemfile: https://github.com/search?q=org%3AShopify+RUBY_VERSION+path%3AGemfile&type=code but never conditional dependency based on version in the gemspec https://github.com/search?q=org%3AShopify+%22RUBY_VERSION%22+path%3A*.gemspec&type=code&p=1 etc.

Yes, I believe Shopify has the largest Ruby and Rails code base in the world, and I have a lot of respect for them. I added “logger” to your search string and got a single hit, https://github.com/Shopify/statsd-instrument/blob/6fd8c49d50803bbccfcc11b195f9e334a6e835e9/Gemfile#L23-L26. It does not have a version constraint on logger. I asked Copilot why it was in the Gemfile and not the gemspec and it explained that using the Gemfile, the evaluation is made at `bundle install` time, whereas in the gemspec it will be made at `gem build` time. So I stand corrected about this, this makes sense, and had not occurred to me. Also, contrary to your findings, the Gemfile.lock file is not committed to the repo. This makes sense to me because managing conflicting logger versions of multiple dependent gems would be IMO an unnecessary nightmare. Or am I missing something? The whole Gemfile/gemspec thing could probably use a thorough review and update. I appreciate that you are investing so much effort and expertise in this.

…

— Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAG56R46F37B556O2MTXI32NKCBRAVCNFSM6AAAAABV46NXNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRVGQ4DOMBSG4>. You are receiving this because you commented.

[noraj]

I appreciate that you are investing so much effort and expertise in this.

I ❤️ Ruby so much I'm happy to help others learn more about it and its ecosystem.

And thank you for your contributions to dnsruby!