Fix dependency locking for path source

[mtsmfm]

What was the end-user or developer problem that led to this PR?

Fix #4098

What is your fix for the problem, implemented in this PR?

To be honest, I don't have enough confidence though I think these dependency check is not necessary because no test fails.

It was added in rubygems/bundler@19192a3 and the test still be there.

rubygems/bundler/spec/install/gemfile/path_spec.rb

Lines 503 to 521 in 9b50ef6

	describe "when dependencies in the path are updated" do
	before :each do
	build_lib "foo", "1.0", :path => lib_path("foo")
	install_gemfile <<-G
	source "#{file_uri_for(gem_repo1)}"
	gem "foo", :path => "#{lib_path("foo")}"
	G
	end
	it "gets dependencies that are updated in the path" do
	build_lib "foo", "1.0", :path => lib_path("foo") do |s|
	s.add_dependency "rack"
	end
	bundle "install"
	expect(the_bundle).to include_gems "rack 1.0.0"
	end

Please let me know if you find a problem with this change.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[welcome]

Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

[ayanko]

It fixes https://github.com/ayanko/bundler-gemspec-issue.
Not sure how does it impact on other cases.

Method converge_locked_specs is huge and complicated.
Should we split it to more multiple methods to increase clarity?

[deivid-rodriguez]

Be my guest!

[deivid-rodriguez]

This is awesome @mtsmfm, thanks so much!

We have a whole different logic for unlocking path sources under converge_paths, so I don't see any immediate issues with doing this.

Plus, I'm strongly opposed to rejecting PRs that remove code, fix an issue and add a spec for the fixed issue. 😃