This is an interesting dilemma. What I'm hearing is there are two valid and important use-cases. TM needs to link against a stable version of something for much of its own functionality to be reliable and predictable.

Meanwhile, clearly a lot of devs need the ability to write code against whatever Ruby version their project requires. (Same goes for other languages really)

It sounds like a reasonable feature that TM should be able to do both.

Users should be unaware of what versions of what TM itself relies on under the hood, but want to be able to write code with whatever language version they need.

This kind of separation and feature makes a lot of sense for long term adoption of TM.

Sent from my iPhone

On 2013/03/24, at 21:00, textmate-request@lists.macromates.com wrote:

...

I have modified TextMate's PATH so that it starts like this:

/Users/mattleopard/.rbenv/bin:/Users/mattleopard/.rbenv/shims: ...

The first is so that the "rbenv" command itself is visible. The second is so that rbenv's "ruby", "rdoc", "gem" and other shims are visible.

OK, so it sounds like this might work (be aware that only 2.0 will expand $HOME and $PATH in your variable settings):

TM_RUBY = "$HOME/.rbenv/shims/ruby" TM_RI = "$HOME/.rbenv/shims/ri" PATH = "$PATH:$HOME/.rbenv/bin"

I don?t know if the last line is required (for the shims to function), but by appending to PATH we don?t eclipse any of the standard tools, so it does no harm for TextMate.

...

So, I'm not sure where TextMate is headed with this, but I hope it's in the direction of playing even *more* nicely with rbenv and my choice of global ruby version - not less nicely. I have a lot of functionality built upon this; obviously I don't want it to break. m.

As mentioned in my previous reply, we?ll (hopefully soon) start to hardcode the /path/to/ruby to make it robust against user alterations.