Wrong version of Puma booted when using relative paths in Gemfile

[Sten Larsson]

Puma-dev will try to run Puma through bundle exec to get the correct version:

puma-dev/dev/app.go

Lines 254 to 258 in 8907643

 if test -e Gemfile && bundle exec puma -V &>/dev/null; then 
 	exec bundle exec puma -C $CONFIG --tag puma-dev:%s -w $WORKERS -t 0:$THREADS -b unix:%s 
 fi 
  
 exec puma -C $CONFIG --tag puma-dev:%s -w $WORKERS -t 0:$THREADS -b unix:%s' 

However, the if-statement fails if you have relative paths in your Gemfile. Let's say I have an app called foo. In my Gemfile I have something like this:

gem 'bar', path: '../bar'

Then when puma-dev runs bundle exec puma -V it will get an error (you can see the error if you put the command in .powenv):

bundler: failed to load command: puma (/Users/stenlarsson/.rbenv/versions/2.3.3/bin/puma)
Bundler::PathError: The path `/Users/stenlarsson/.puma-dev/bar` does not exist.
...

The problem is that the current working directory is ~/.puma-dev/foo. When (the wrong version of) Puma has booted it works, so Puma must have resolved the symlink, but I guess it needs to be done before running bundle exec.

[Alan Norton]

🤔

If we have a Gemfile and expect to be bundled, then we probably shouldn't fall back to the non-bundled version if puma fails.

We can certainly expand the symlink to the absolute path, but not sure if there's a single chokepoint to do that right now.

Feels like there's more to the story here than just relative gem paths.