Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

"bundle clean" removes git dependencies with RubyGems 3+ when path involves symlink #7208

Closed
GUI opened this issue Jun 15, 2019 · 1 comment · Fixed by #7211
Closed

"bundle clean" removes git dependencies with RubyGems 3+ when path involves symlink #7208

GUI opened this issue Jun 15, 2019 · 1 comment · Fixed by #7211

Comments

@GUI
Copy link

GUI commented Jun 15, 2019

The bundle clean command removes gems that are still being used if all 3 of these criteria are true:

  1. RubyGems 3.0+ is being used.
  2. The bundler installation path contains a symlink anywhere in the path (it could be the final directory, or any intermediate).
  3. A git dependency is present in your Gemfile.

If all 3 of these situations apply, then bundle clean will always remove the git dependencies present in your Gemfile, despite the fact that those gems are still in use. This occurs in both Bundler 2 and Bundler 1.7.

I'm wondering if this is related to these symlink changes in RubyGems 3.0: rubygems/rubygems#2352 However, since this issue is specific to git dependencies supported by Bundler, that's why I'm filing the ticket here, but let me know if I should file this on RubyGems instead.

Here's a demonstration of the issue (with Bundler 2.0.2, but the same behavior is seen with Bundler 1.17.3 as long as RubyGems 3+ is used):

# Create a Gemfile with a git dependency.
mkdir test-bundler
cd test-bundler
printf 'source "https://rubygems.org"\ngem "rack", :git => "https://github.com/rack/rack.git"' > Gemfile

# Create a symlink
mkdir real-path
ln -s real-path symlink-path

# Ruby, RubyGems, and Bundler versions
ruby --version
# ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin16]
gem update --system 3.0.4
gem install bundler --version 2.0.2
gem --version
# 3.0.4
bundle --version
# Bundler version 2.0.2

# Install to symlink
bundle install --path=./symlink-path

# Run "bundle clean", which removes the git dependency.
bundle clean --verbose
# Running `bundle clean --verbose` with bundler 2.0.2
# Found no changes, using resolution from the lockfile
# Removing rack (70c838f7204f)

bundle exec ruby -e 'puts "Hello, world."'
# https://github.com/rack/rack.git (at master@70c838f) is not yet checked out. Run `bundle install` first.

Note that this issue does not occur if you're not using a symlink in RubyGems 3+:

gem --version
# 3.0.3
bundle --version
# Bundler version 2.0.2

bundle install --path=./real-path

bundle clean --verbose
# Running `bundle clean --verbose` with bundler 2.0.2
# Found no changes, using resolution from the lockfile

bundle exec ruby -e 'puts "Hello, world."'
# Hello, world.

It also does not occur if you are using a symlink, but are using RubyGems 2:

gem update --system 2.7.10

gem --version
# 2.7.10
bundle --version
# Bundler version 2.0.2

bundle install --path=./symlink-path

bundle clean --verbose
# Running `bundle clean --verbose` with bundler 2.0.2
# Found no changes, using resolution from the lockfile

bundle exec ruby -e 'puts "Hello, world."'
# Hello, world.
@deivid-rodriguez
Copy link
Member

Thanks for the super clean repro. This should be fixed by #7211.

ghost pushed a commit that referenced this issue Jun 18, 2019
7211: Use real paths for `bundle clean` r=colby-swandale a=deivid-rodriguez

Fixes #7208.

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

The problem was that since rubygems 3.0, `bundle clean` incorrectly cleans git gems when they are installed to a symlinked location, but still being used.

### What was your diagnosis of the problem?

My diagnosis was that since rubygems/rubygems#2352, `Gem.dir` returns an array of realpaths, not symlinked ones. However, we don't do the same resolution on the `bundler` side, so in this situation git gems are not correctly skipped from the cleanup.

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

My fix is to resolve the array of paths `bundle clean` uses to do its thing into an array of real paths, just like rubygems does now.

### Why did you choose this fix out of the possible options?

I chose this fix because it fixes the problem.


Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
@ghost ghost closed this as completed in #7211 Jun 18, 2019
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants