Change PATH based on Gemfile

.bashrc

source "/home/judson/bin/bundler_ps1.sh"

if [[ ! $PROMPT_COMMAND =~ __bundler_prompt_command ]]; then
  export PROMPT_COMMAND="${PROMPT_COMMAND:-:} ; __bundler_prompt_command"
fi

PS1="\[\033[01;31m\]\$(__bundler_ps1)\[\033[01;34m\] $PS1"

bundle_setup.sh

#!/bin/sh

BUNDLE_BASE=~/ruby/bundle-paths/

if [ -f .bundle/config ]; then
  echo "Bundle config file already exists"
  bundle install
else
  projname=$(basename $(pwd))
  BUNDLE_PATH="$BUNDLE_BASE/lib"
  BINSTUBS=".bundle/bin"

  echo "Setting up bundle for $projname"
  bundle install --path=$BUNDLE_PATH --binstubs=$BINSTUBS
fi

bundler_ps1.sh

export bundle_dir=""
export bundle_bin=""
export orig_path=$PATH

function find_bundle_dir() {
  bundle_dir=$(pwd)
  while [ $bundle_dir != "/" ]; do
    if [ -e $bundle_dir/.bundle/config ]; then
      return 0
    fi
    bundle_dir=$(dirname $bundle_dir)
  done
  bundle_dir=""
  export bundle_dir
  echo $bundle_dir

  return 1
}

function bundle_config_changed() {
  local old_dir=$bundle_dir

  find_bundle_dir

  if [ "$bundle_dir" != "$old_dir" ]; then
    return 0
  else
    return 1
  fi
}


function __bundler_prompt_command(){
  if bundle_config_changed; then
    if [ ! -z "$bundle_bin" ]; then
      export PATH=$(echo $PATH | sed "s!${bundle_bin}\:!!")
    fi
    if [ -e $bundle_dir/.bundle/config ]; then
      export bundle_bin=$(cat $bundle_dir/.bundle/config | grep BUNDLE_BIN | awk '{ print $2 }')
    else
      export bundle_bin=""
    fi
  fi

  if echo $PATH | grep -q -v "$bundle_bin";  then
    export PATH=$bundle_bin:$PATH
  fi
}

function __bundler_ps1(){
  if [ ! -z "$bundle_bin" ]; then
    if echo $PATH | grep -q "$bundle_bin"; then
      echo -n 'B '
    fi
  fi
}

Which means...

judson@dijkstra /home/judson $ echo $PATH
~/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/games/bin

judson@dijkstra /home/judson $ cd ruby/gems/vizier/
B judson@dijkstra .../gems/vizier $ echo $PATH
/home/judson/ruby/bundle-paths/vizier/bin:~/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/games/bin
                                    
B judson@dijkstra .../gems/vizier $ cd ../../LRD/ecliptic/
B judson@dijkstra .../LRD/ecliptic (master) $ echo $PATH
/home/judson/ruby/bundle-paths/ecliptic/bin:~/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.3:/usr/games/bin

I find this fascinating!

I might give this a try. Is it still working for you or have you modified your use since you created this gist?

I have been trying to dealing with the infrastructure that surrounds ruby on rails for over a year now. I find myself spending way more time than I have dealing all the different tools and their versions and configurations. I have been striving to find the simplest, leanest, least intrusive methods I can. I gave up on RVM and gemsets, and though I may use rbenv if I need more than one ruby. I find that I prefer to use virtual machines for the basic OS and ruby. This leaves me still working out issues with system libraries and native compiles but I am getting there.

However, I am still am a bit confused about project gems versus system gems and when I should use bundler exec (not to mention trying to package the project up for deployment).

Your gist seems a very elegant and very unix way to layer access to the gems through the PATH. Kudos! Correct me if I am wrong but this will let me type rake... and if I am in a project root, I get the project binstub for rake and if I am NOT in a project I get the system level rake?

Slightly off topic, what gems does one actually need at the system level versus gems that you only need in your rails project? It seems to me that you all you need are rubygems, rake, rails (only to make a new project) and bundler. What else would you need that you couldn't manage from inside your project using a Gemfile?

Thanks! I've been really pleased with it, and still use it today. Obviously, most of the credit goes to @wycats and the rest of the Bundler and Rubygems teams.

Since posting this gist, I made a little tweak to my .bashrc - I just updated the gist to reflect that change. The upshot is that now it'll work with other tools that modify PROMPT_COMMAND. Specifically, I use the very excellent autojump, which uses PROMPT_COMMAND to record pwd over time.

As to using multiple Rubys, there are a few answers - I think rbenv is a possiblity. My OS provides a utility to switch out components that mostly works (I'm less than thrilled with how it handles Passenger...) Full VMs will certainly swat that fly, though.

Yes: in a project, rake will run using the project's rake, etc. Likewise rails will run with the local Gemfile.

rake, rails and bundler are probably sufficient (rubygems is itself not precisely a gem) I sometimes install other gems just to get their rdoc installed, though.

The update looks great. I had not thought about other command_prompt tools. Though, I have an idea for one myself ;-)

I am so busy that I will not have time to try this out until the weekend. But I am definitely going to give a shot.

Again on the off topic system versus bundler gems. I suppose sometimes the designers are too close to their projects to explain the BIG picture to neophytes like myself, but I could not really get the idea that I had to use rails to make a rails project. Meaning that there are two levels of usage - it is a tool and "library". This became very confusing for me once I had more that one version of rails on my system. And I could not really find a doc or tutorial that clearly explained this -- and I have read a lot of them

I only just found out how to select which version of a system gem to run from the command line by passing its version number quoted by underscores. IOW, if I have rails 3.2.2, 3.1.11 and 2.3.5 installed as system gems I can build a new rails 2.3.5 project using:

rails _2.3.5_ my_app

OR a rails 3.1.11project using:

rails _3.1.11_ new myapp 

and plain:

rails new myapp

gets me a 3.2.2 project.

The irony is that I cannot find blurb where I read this again! I really do not want to test it until I can find some real documentation on it -- oh well, sorry for the side track...

Anyway I will let you know how it goes with your code next week. Thanks for implementing a great idea!