Skip to content

Commit

Permalink
⚡️ require_relative > require for internal files
Browse files Browse the repository at this point in the history
  • Loading branch information
pboling committed Sep 19, 2024
1 parent fc7c2f5 commit 72b8041
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 14 deletions.
15 changes: 8 additions & 7 deletions lib/gem_bench.rb
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,14 @@
require "version_gem"
require "bundler" # This gem utilizes bundler as a tool.

require "gem_bench/version"
require "gem_bench/scout"
require "gem_bench/player"
require "gem_bench/team"
require "gem_bench/gemfile_line_tokenizer"
require "gem_bench/strict_version_gem"
require "gem_bench/strict_version_requirement"
# this library
require_relative "gem_bench/version"
require_relative "gem_bench/scout"
require_relative "gem_bench/player"
require_relative "gem_bench/team"
require_relative "gem_bench/gemfile_line_tokenizer"
require_relative "gem_bench/strict_version_gem"
require_relative "gem_bench/strict_version_requirement"

module GemBench
USAGE = "[GemBench] Usage: Require another gem in this session to evaluate it.\n\tExample:\n\t\trequire 'rails'\n\t\tGemBench.check({verbose: true})\n"
Expand Down
13 changes: 6 additions & 7 deletions lib/gem_bench/jersey.rb
Original file line number Diff line number Diff line change
Expand Up @@ -110,15 +110,14 @@ def as_klass
private

def load_gem_copy(files)
puts "Requiring copy of #{gem_name} with: #{files.inspect}" if verbose
# These are absolute file paths, so they can use `require`
files.each do |filepath|
# begin
# But files required here may not load their own internal files properly if they are still using `require`.
# Since Ruby 2.2, best practice for ruby libraries is to use require_relative for internal files,

This comment has been minimized.

Copy link
@tagliala

tagliala Sep 20, 2024

is there a reference to this best practice?

This comment has been minimized.

Copy link
@pboling

pboling Sep 20, 2024

Author Owner

I think you already found it based on the links in your commits yesterday, but for other googlers...

rubocop/rubocop#8748 (comment)

It should also be noted that there is an important caveat when packaging a gem for Debian matters (it does for many of my gems!).

In the test / spec directory the preference is more refined:

  • require > require_relative, for all of the gem's lib files
  • require > require_relative, for all external gems & stdlibs.
  • require_relative > require, for test / spec internal files (e.g. spec/support/rspec_config.rb)

Cheers! 🥇

This comment has been minimized.

Copy link
@tagliala

tagliala Sep 20, 2024

packaging a gem for Debian

Yes, I read that but I didn't understand exactly what it means and the consequences. Is it related to binaries or something like that?

what is a "gem for debian" doing compared to "other" gems? is this related to binaries?

This comment has been minimized.

Copy link
@tagliala

tagliala Sep 20, 2024

sorry!

I read > as "greater than" and I thought that for Debian using "require" would be better than "require_relative" in lib

This comment has been minimized.

Copy link
@pboling

pboling Sep 20, 2024

Author Owner

As was briefly mentioned in that same RuboCop thread, the Debian project had a summer of code intern working on improving the state of gems packaged with Debian, as part of the system Ruby install. This includes many gems, including some that I maintain, like oauth, oauth2, and omniauth-identity IIRC.

As part of that effort they created a rubocop plugin gem, called rubocop-packaging, which I now add to all my gems as a development dependency. It ensures there is no dependency on a git executable from the gemspec, as well as the require_relative thing.

Now that the summer of code thing is over that intern is now working full time on Debian, including maintaining the Debian forks of ruby gems. Ideally they wouldn't have to maintain a full set of forks, but for that to be possible gem maintainers must begin following the rules. 🗡

This comment has been minimized.

Copy link
@pboling

pboling Sep 20, 2024

Author Owner

require is better than require_relative for Debian, but only for files in test / spec which load the gem under test.

For files in lib it remains as:

  • require_relative is better than require for internal files, and
  • require is better than require_relative for external files.

This comment has been minimized.

Copy link
@tagliala

tagliala Sep 20, 2024

Thanks for the clarification and for rubocop-packaging informations

I've added that extension to all the gems that I'm contributing to and we are git-free on memo_wise too

I've stayed conservative by only changing requires from lib to lib

It ensures there is no dependency on a git executable from the gemspec, as well as the require_relative thing.

I'm not getting flagged about requires, and I've read the docs, probably I'm missing something

Sorry for the off topic

This comment has been minimized.

Copy link
@pboling

pboling Sep 20, 2024

Author Owner

I admit, I've also never seen that particular Cop flag anything for me, and I expect it should have, as I've used it since it was created, on dozens of gems. Perhaps it has a bug.

This comment has been minimized.

Copy link
@pboling

pboling Sep 20, 2024

Author Owner

This was wrong. require_relative was introduced in Ruby 1.9.2, not 2.2. Had my wires crossed. Has been fixed in main branch.

# and require for external files and dependencies.
# Ref: https://github.com/panorama-ed/memo_wise/issues/349
require filepath
# rescue LoadError => e
# puts file.to_s
# puts tempfile.path
# puts e.class
# puts e.message
# end
end
end

Expand Down

0 comments on commit 72b8041

Please sign in to comment.