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

nested bundle exec, not working in Ruby trunk/head #7244

Closed
MSP-Greg opened this issue Jul 10, 2019 · 8 comments · Fixed by #7248
Closed

nested bundle exec, not working in Ruby trunk/head #7244

MSP-Greg opened this issue Jul 10, 2019 · 8 comments · Fixed by #7248

Comments

@MSP-Greg
Copy link
Contributor

MSP-Greg commented Jul 10, 2019

Only on Ruby trunk/head, there's a Travis CI test issue with Puma that generates a LoadError, where a bundle exec command is generated within a process started via bundle exec.

So, I used the following command:

bundle exec "bundle exec 'ruby -v'"

Works fine with Ruby 2.6.3, RG 3.0.3, & bundler 2.0.1.

With Ruby trunk/master/head/2.7.0 (RG 3.1.0.pre1, bundler 2.1.0.pre.1), it fails on the line in the bin stub:

load Gem.activate_bin_path('bundler', 'bundle', version)

Correct value is:

lib/ruby/gems/2.7.0/gems/bundler-2.1.0.pre.1/exe/bundle

nested value is the following, which doesn't exist, and generates the LoadError:

lib/bin/bundle

EDIT:

Sorry for not making it explicitly clear, but bundle exec "ruby -v" works fine in both. The only issue is nested bundle exec's, which may be common in testing started with 'bundle exec rake <test>`...

@MSP-Greg MSP-Greg changed the title nested bundle exec, not working in Ruby trunk/ead nested bundle exec, not working in Ruby trunk/head Jul 10, 2019
@deivid-rodriguez
Copy link
Member

I tried this on current master and it seems to work, so this should probably be fixed once a newer bundler commit is used in ruby-core. I did this on current master, not sure if it fully represents the case you're seeing:

~/Code/bundler $ touch Gemfile
~/Code/bundler $ RUBYOPT=-Ilib exe/bundle exec 'bundle exec "ruby -v"'
Resolving dependencies...
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]

@MSP-Greg
Copy link
Contributor Author

Fixed in ruby/ruby#2285

@MSP-Greg
Copy link
Contributor Author

MSP-Greg commented Jul 10, 2019

@deivid-rodriguez

You have to use Ruby trunk/master/2.7.0. Explanation in the above Ruby PR...

@deivid-rodriguez
Copy link
Member

deivid-rodriguez commented Jul 10, 2019

You don't make PRs to ruby-core for bundler. You make PRs to the bundler repo, and then they are backported to ruby.

Currently the ruby repo is using an older reference than current bundler's master, and the issue you mention is not reproducible on bundler's master. Once ruby-core is updated to the latest bundler, the issue should be fixed since I can't reproduce it here.

@deivid-rodriguez
Copy link
Member

Sorry @MSP-Greg, I read your PR now. No idea whether it is correct or not, but the case for a regular bundler installation shouldn't be affected, so I guess if that fixes some failures in core, it's fine? @hsbt will know best... 🤷‍♂️

@MSP-Greg
Copy link
Contributor Author

@deivid-rodriguez

Thanks. I saw your previous response, and assumed you hadn't read the PR.

Yes and yes. I'm not sure if Gem.dir always points to the 'internal' gem folder where default and bundled gems/specs are stored. There's too many OS's out there, but it's an improvement on the current, which breaks some CI testing (Ruby trunk only) that uses nested bundle exec's.

I'm kind of sensitive about trunk failures...

@MSP-Greg
Copy link
Contributor Author

so I guess if that fixes some failures in core

Actually, the failure is a result of bundler being installed as a default gem, so that really isn't a 'Ruby core' issue, it's just that core/trunk is the only place that happens.

I don't know what exactly the 'integration plans' are, but if RG and Bundler will be separate default gems as they are in trunk...

Regardless, this breaks trunk CI, and considering that a few times when I've suggested that repos test against it, they complain about failures, issues like this should get fixed in a prompt manner, regardless of upstream, downstream, or a body of water.

Lastly, I have no idea how to write a test for this, as the failure happens when the bundler exe folder is in its installed location...

@MSP-Greg
Copy link
Contributor Author

@deivid-rodriguez

Just looked into this a little further (as opposed to while taking a break from a mess), and the issue is a result of a PR of yours. Not being critical, as this is an edge case. See e742c3d and #7100.

See PR #7248.

I may add a test for this in ruby-loco, as I've already got several 'CLI' tests...

ghost pushed a commit that referenced this issue Jul 19, 2019
7248: Fix nested bundle exec's when bundler is a default gem r=deivid-rodriguez a=MSP-Greg

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

The problem was that when bundler is a default gem, nested `bundle exec` commands generate a LoadError.

```
/home/travis/.rvm/rubies/ruby-head/bin/bundle:30:in `load': cannot load such file --
/home/travis/.rvm/rubies/ruby-head/lib/bin/bundle (LoadError)
```

### What was your diagnosis of the problem?

Not accounting for Bundler being installed as a default gem. When it's a default, the lib and exe folders do not share the same root folder.

This was the result of a change in e742c3d (#7100).

### Repo Example

Using Ruby master/trunk/ruby-head (as of ruby/ruby@0c6c937), from a folder where `bundle exec` can be ran:

```
bundle exec "bundle exec 'ruby -v'"
```

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

Small adjustment to logic for finding the correct exe/bundle file.

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

I chose this fix because it's similar to previous code.

Fixes #7244.

Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
@ghost ghost closed this as completed in #7248 Jul 19, 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