1
0
Fork 0
mirror of https://github.com/ruby/ruby.git synced 2022-11-09 12:17:21 -05:00
ruby--ruby/spec/bundler/support/path.rb

192 lines
4.3 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
require "pathname"
require "rbconfig"
module Spec
module Path
def root
@root ||= Pathname.new(ruby_core? ? "../../../.." : "../../..").expand_path(__FILE__)
end
def gemspec
@gemspec ||= root.join(ruby_core? ? "lib/bundler/bundler.gemspec" : "bundler.gemspec")
end
def gemspec_dir
@gemspec_dir ||= gemspec.parent
end
def bindir
@bindir ||= root.join(ruby_core? ? "libexec" : "exe")
end
def gem_cmd
@gem_cmd ||= ruby_core? ? root.join("bin/gem") : "gem"
end
def gem_bin
@gem_bin ||= ruby_core? ? ENV["GEM_COMMAND"] : "gem"
end
def spec_dir
@spec_dir ||= root.join(ruby_core? ? "spec/bundler" : "spec")
end
def tracked_files
2019-12-14 05:49:16 -05:00
skip "not in git working directory" unless git_root_dir?
Fix some bundler specs (#2380) * These seem to consistenly pass already * Show actual command when running `make test-bundler` Current the setup command that installs the necessary gems for testing bundler was printed, but not the actual command that runs the tests. That was a bit confusing. * Borrow trick from setproctitle specs * A title that long doesn't get set sometimes No idea why, but the test doesn't need that the title is that long. * Fix most gem helper spec ruby-core failures * Fix the rest of the gem helper failures * Fix version spec by improving the assertion * Remove unnecessary `BUNDLE_RUBY` environment var We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name because bundler considers `BUNDLE_*` variables as settings. * Rename `BUNDLE_GEM` to `GEM_COMMAND` This is more descriptive I think, and also friendlier for bundler because `BUNDLE_` env variables are interpreted by bundler as settings, and this is not a bundler setting. This fixes one bundler spec failure in config specs against ruby-core. * Fix quality spec when run in core Use the proper path helper. * Fix dummy lib builder to never load default gems If a dummy library is named as a default gem, when requiring the library from its executable, the default gem would be loaded when running from core, because in core all default gems share path with bundler, and thus they are always in the $LOAD_PATH. We fix the issue by loading lib relatively inside dummy lib executables. * More exact assertions Sometimes I have the problem that I do some "print debugging" inside specs, and suddently the spec passes. This happens when the assertion is too relaxed, and the things I print make it match, specially when they are simple strings like "1.0" than can be easily be part of gem paths that I print for debugging. I fix this by making a more exact assertion. * Detect the correct shebang when ENV["RUBY"] is set * Relax assertion So that the spec passes even if another paths containing "ext" are in the load path. This works to fix a ruby-core issue, but it's a better assertion in general. We just want to know that the extension path was added. * Use folder structure independent path helper It should fix this spec for ruby-core. * Fix the last failing spec on ruby-core * Skip `bundle open <default_gem>` spec when no default gems
2019-08-19 20:46:31 -04:00
@tracked_files ||= ruby_core? ? `git ls-files -z -- lib/bundler lib/bundler.rb spec/bundler man/bundler*` : `git ls-files -z`
end
def shipped_files
2019-12-14 05:49:16 -05:00
skip "not in git working directory" unless git_root_dir?
Fix some bundler specs (#2380) * These seem to consistenly pass already * Show actual command when running `make test-bundler` Current the setup command that installs the necessary gems for testing bundler was printed, but not the actual command that runs the tests. That was a bit confusing. * Borrow trick from setproctitle specs * A title that long doesn't get set sometimes No idea why, but the test doesn't need that the title is that long. * Fix most gem helper spec ruby-core failures * Fix the rest of the gem helper failures * Fix version spec by improving the assertion * Remove unnecessary `BUNDLE_RUBY` environment var We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name because bundler considers `BUNDLE_*` variables as settings. * Rename `BUNDLE_GEM` to `GEM_COMMAND` This is more descriptive I think, and also friendlier for bundler because `BUNDLE_` env variables are interpreted by bundler as settings, and this is not a bundler setting. This fixes one bundler spec failure in config specs against ruby-core. * Fix quality spec when run in core Use the proper path helper. * Fix dummy lib builder to never load default gems If a dummy library is named as a default gem, when requiring the library from its executable, the default gem would be loaded when running from core, because in core all default gems share path with bundler, and thus they are always in the $LOAD_PATH. We fix the issue by loading lib relatively inside dummy lib executables. * More exact assertions Sometimes I have the problem that I do some "print debugging" inside specs, and suddently the spec passes. This happens when the assertion is too relaxed, and the things I print make it match, specially when they are simple strings like "1.0" than can be easily be part of gem paths that I print for debugging. I fix this by making a more exact assertion. * Detect the correct shebang when ENV["RUBY"] is set * Relax assertion So that the spec passes even if another paths containing "ext" are in the load path. This works to fix a ruby-core issue, but it's a better assertion in general. We just want to know that the extension path was added. * Use folder structure independent path helper It should fix this spec for ruby-core. * Fix the last failing spec on ruby-core * Skip `bundle open <default_gem>` spec when no default gems
2019-08-19 20:46:31 -04:00
@shipped_files ||= ruby_core? ? `git ls-files -z -- lib/bundler lib/bundler.rb man/bundler* libexec/bundle*` : `git ls-files -z -- lib man exe CHANGELOG.md LICENSE.md README.md bundler.gemspec`
end
def lib_tracked_files
2019-12-14 05:49:16 -05:00
skip "not in git working directory" unless git_root_dir?
@lib_tracked_files ||= ruby_core? ? `git ls-files -z -- lib/bundler lib/bundler.rb` : `git ls-files -z -- lib`
end
def tmp(*path)
root.join("tmp", scope, *path)
end
def scope
test_number = ENV["TEST_ENV_NUMBER"]
return "1" if test_number.nil?
test_number.empty? ? "1" : test_number
end
def home(*path)
tmp.join("home", *path)
end
def default_bundle_path(*path)
if Bundler::VERSION.split(".").first.to_i < 3
system_gem_path(*path)
else
bundled_app(*[".bundle", ENV.fetch("BUNDLER_SPEC_RUBY_ENGINE", Gem.ruby_engine), RbConfig::CONFIG["ruby_version"], *path].compact)
end
end
def bundled_app(*path)
root = tmp.join("bundled_app")
FileUtils.mkdir_p(root)
root.join(*path)
end
alias_method :bundled_app1, :bundled_app
def bundled_app2(*path)
root = tmp.join("bundled_app2")
FileUtils.mkdir_p(root)
root.join(*path)
end
def vendored_gems(path = nil)
bundled_app(*["vendor/bundle", Gem.ruby_engine, RbConfig::CONFIG["ruby_version"], path].compact)
end
def cached_gem(path)
bundled_app("vendor/cache/#{path}.gem")
end
def base_system_gems
tmp.join("gems/base")
end
def file_uri_for(path)
protocol = "file://"
root = Gem.win_platform? ? "/" : ""
protocol + root + path.to_s
end
def gem_repo1(*args)
tmp("gems/remote1", *args)
end
def gem_repo_missing(*args)
tmp("gems/missing", *args)
end
def gem_repo2(*args)
tmp("gems/remote2", *args)
end
def gem_repo3(*args)
tmp("gems/remote3", *args)
end
def gem_repo4(*args)
tmp("gems/remote4", *args)
end
def security_repo(*args)
tmp("gems/security_repo", *args)
end
def system_gem_path(*path)
tmp("gems/system", *path)
end
def lib_path(*args)
tmp("libs", *args)
end
def lib_dir
root.join("lib")
end
def global_plugin_gem(*args)
home ".bundle", "plugin", "gems", *args
end
def local_plugin_gem(*args)
bundled_app ".bundle", "plugin", "gems", *args
end
def tmpdir(*args)
tmp "tmpdir", *args
end
def with_root_gemspec
if ruby_core?
root_gemspec = root.join("bundler.gemspec")
2019-11-18 09:41:26 -05:00
# Dir.chdir(root) for Dir.glob in gemspec
spec = Dir.chdir(root) { Gem::Specification.load(gemspec.to_s) }
spec.bindir = "libexec"
File.open(root_gemspec.to_s, "w") {|f| f.write spec.to_ruby }
yield(root_gemspec)
FileUtils.rm(root_gemspec)
else
yield(gemspec)
end
end
def ruby_core?
# avoid to warnings
@ruby_core ||= nil
if @ruby_core.nil?
Fix some bundler specs (#2380) * These seem to consistenly pass already * Show actual command when running `make test-bundler` Current the setup command that installs the necessary gems for testing bundler was printed, but not the actual command that runs the tests. That was a bit confusing. * Borrow trick from setproctitle specs * A title that long doesn't get set sometimes No idea why, but the test doesn't need that the title is that long. * Fix most gem helper spec ruby-core failures * Fix the rest of the gem helper failures * Fix version spec by improving the assertion * Remove unnecessary `BUNDLE_RUBY` environment var We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name because bundler considers `BUNDLE_*` variables as settings. * Rename `BUNDLE_GEM` to `GEM_COMMAND` This is more descriptive I think, and also friendlier for bundler because `BUNDLE_` env variables are interpreted by bundler as settings, and this is not a bundler setting. This fixes one bundler spec failure in config specs against ruby-core. * Fix quality spec when run in core Use the proper path helper. * Fix dummy lib builder to never load default gems If a dummy library is named as a default gem, when requiring the library from its executable, the default gem would be loaded when running from core, because in core all default gems share path with bundler, and thus they are always in the $LOAD_PATH. We fix the issue by loading lib relatively inside dummy lib executables. * More exact assertions Sometimes I have the problem that I do some "print debugging" inside specs, and suddently the spec passes. This happens when the assertion is too relaxed, and the things I print make it match, specially when they are simple strings like "1.0" than can be easily be part of gem paths that I print for debugging. I fix this by making a more exact assertion. * Detect the correct shebang when ENV["RUBY"] is set * Relax assertion So that the spec passes even if another paths containing "ext" are in the load path. This works to fix a ruby-core issue, but it's a better assertion in general. We just want to know that the extension path was added. * Use folder structure independent path helper It should fix this spec for ruby-core. * Fix the last failing spec on ruby-core * Skip `bundle open <default_gem>` spec when no default gems
2019-08-19 20:46:31 -04:00
@ruby_core = true & ENV["GEM_COMMAND"]
else
@ruby_core
end
end
extend self
2019-12-14 05:49:16 -05:00
private
def git_root_dir?
root.to_s == `git rev-parse --show-toplevel`.chomp
end
end
end