RubyGems
Replies: 1 comment 7 replies
-
|
I have the same expectation you have 🤔 I tried writing a spec to represent your situation and it worked as we both expect. Does this sounds like the kind of setup you have? + context "when a top-level gem has an indirect dependency present in the default source, but with a higher version from the one resolved" do
+ before do
+ build_lib "vc_gem", "1.0.0", :path => bundled_app do |s|
+ s.add_dependency "my_gem", "1.0.0"
+ end
+
+ build_repo gem_repo4 do
+ build_gem "my_gem", "1.0.0"
+ build_gem "my_gem", "3.0.0"
+ end
+
+ gemfile <<-G
+ source "https://gem.repo2"
+
+ gemspec
+
+ source "https://gem.repo4" do
+ gem "my_gem"
+ end
+ G
+ end
+
+ it "installs all gems without warning" do
+ bundle :install, :artifice => "compact_index"
+ expect(the_bundle).to include_gem("my_gem 1.0.0")
+ end
+ end
+
|
Beta Was this translation helpful? Give feedback.
-
|
It gets weirder. If I change the gemspec requirement to use a version of OK, that's all consistent with the apparent bug evidenced above. Repeat with Remove the That final state is the second commit, still with the unexpected version in the Here's the EnvironmentBundler Build MetadataBundler settingsGemfileGemfile# frozen_string_literal: true
source "https://rubygems.org"
# Specify your gem's dependencies in bundler-dry_version.gemspec
gemspec
gem "rubocop-lts"Gemfile.lockGemspecsbundler-dry_version.gemspec# frozen_string_literal: true
require_relative "lib/bundler/dry_version/version"
Gem::Specification.new do |spec|
spec.name = "bundler-dry_version"
spec.version = Bundler::DryVersion::VERSION
spec.authors = ["Peter Boling"]
spec.email = ["peter.boling@gmail.com"]
spec.summary = "Bundler + gemspec behavior example"
spec.description = "Demonstrates some confusing behavior of bundler + gemspec
https://github.com/rubygems/rubygems/discussions/6726#discussioncomment-6130139"
spec.homepage = "https://github.com/rubygems/rubygems/discussions/6726#discussioncomment-6130139"
spec.license = "MIT"
spec.required_ruby_version = ">= 2.6.0"
spec.metadata["homepage_uri"] = spec.homepage
spec.metadata["source_code_uri"] = "https://github.com/rubocop-lts/bundler-dry_version"
# Specify which files should be added to the gem when it is released.
# The `git ls-files -z` loads the files in the RubyGem that have been added into git.
spec.files = Dir.chdir(__dir__) do
`git ls-files -z`.split("\x0").reject do |f|
(File.expand_path(f) == __FILE__) || f.start_with?(*%w[bin/ test/ spec/ features/ .git .circleci appveyor])
end
end
spec.bindir = "exe"
spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
spec.require_paths = ["lib"]
# The version here will be constrained to a much lower version that the latest release, which is v24.
# See Gemfile, and Gemfile.lock for the interplay.
spec.add_development_dependency "rubocop-lts", "~> 8.0"
# For more information and examples about making a new gem, check out our
# guide at: https://bundler.io/guides/creating_gem.html
end |
Beta Was this translation helpful? Give feedback.
-
|
Bottom line is I can't get it to work at all... so I'm thinking/hoping maybe your example spec was failing rather than that your spec env is not working. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Nope, the spec I wrote is passing. From your initial report, you have now changed things to use In that case, I need to have another look. It may be related to #6014. For now you can workaround this by removing |
Beta Was this translation helpful? Give feedback.
-
|
I didn't even realize I made that switch. 🤦 I'll see if I can repro it the way I originally reported. Perhaps that was the entire source of my issue. |
Beta Was this translation helpful? Give feedback.
-
|
My confusion definitely came from an expectation I had that the gemspec / Gemfile version specification behavior was the same between runtime and development dependencies, but that is apparently not the case. It works as expected for runtime dependencies, and it works as designed for development dependencies. From now on I will put development dependencies in the Gemfile only, and remove them from all my gemspecs. :) |
Beta Was this translation helpful? Give feedback.
-
When a gem server must be specified, it is currently impossible for gem version requirements to follow the "dry"-paradigm, which can result in some confusing issues.
If I have published a private gem called "my_gem" on a private gemserver, and I have released versions: 1.0.0, 2.0.0, and 3.0.0, each with breaking changes.
If I have an old gem that depends on the older API of 1.0.0, and my Gemspec strictly enforces this:
I have to specify the source in my
Gemfile:I will end up with a
Gemfile.locklike this, which is not entirely expected:Note that the placement of the
gemspecdirective makes no difference, whether before or after thesourceblock.The only way to get the correct source, and the correct version is to (re)specify the version when specifying the source as follows in the
Gemfile:The duplicate declaration of the version is problematic, because, if we add two layers to this cake, I have gem, called "llama" that depends on "my_gem" version 1.0.0, and it will have to reduplicate the version in both its gemspec and its Gemfile.
Then, I have an app that depends on "llama", and it will also have to specify each of these gems as coming from the private server. It will have to duplicate, again, the version requirement of the sub-dependencies that are already explicitly set by each gem, but cannot help but be overridden.
Now make this stack of gems, apps, apps mounted inside other apps, many, many more layers deep, and it is a pain.
Beta Was this translation helpful? Give feedback.
All reactions