rbenv issues

[MatthewMDavis]

First, a documentation issue: the link to rbenv information on the repo main page doesn't go anywhere.

Second, I'm trying to understand why the rbenv segment works the way it does. The segment tests for the RBENV_VERSION environment variable, which only returns true if one has set a shell-specific rbenv version -- one that trumps the global and local settings. So if I'm in a directory that's under a local rbenv version, the prompt won't tell me that.

Obviously, if I do have a shell-specific rbenv version in effect, I'll want my shell to tell me that -- what I want the prompt to tell me is what version of Ruby is in effect, so I'll want to know that my local version is preempted by a shell-specific version. But since I don't, I'm not clear on why this segment is keying on this environment variable, rather than testing to see whether there is an rbenv version in effect right now.

Should I be rigging something up to set this variable equal to the output of 'rbenv version' if I want to have my prompt tell me what version of Ruby is in effect?

[dritter]

Should I be rigging something up to set this variable equal to the output of 'rbenv version' if I want to have my prompt tell me what version of Ruby is in effect?

Ideally no. But maybe you want to improve the segment and share it with us all? 😉

I am not a ruby guy, so I cannot help explain what is happening (or understand you correctly with all that shell-specific rbenv-versions). But maybe @natemccurdy can help?

[natemccurdy]

@MatthewMDavis Hi, I'm the one who wrote the original rbenv segment, so maybe I can help.
Firstly, I wrote the segment for my use-case (which I think is pretty standard based on what I've seen online), so if you use rbenv differently from me, you may likely not be seeing the info you want.

My Usage
I use rbenv on my Mac when I want to test writing Ruby code in different versions than my system Ruby. To do that, I run rbenv shell <some_version> which creates an environmental variable $RBENV_VERSION whose value is the version of Ruby that rbenv is currently using.

When I stop testing, I run rbenv shell --unset which resets the version of Ruby being used to system Ruby. In that process, the environmental variable is unset.

Here's a screenshot that shows that process:

I really only wanted to be notified when I was using a Ruby version other than system Ruby. Hence why I made the segment check for the value of $RBENV_VERSION.

Also, you mentioned a local rbenv version... I am, admittedly, not 100% versed on the usage of rbenv. Does that mean that there can be directory that has it's own ruby version set? Like with a dotfile or something?

[natemccurdy]

Ahh.... To answer my own question, "yes, there are many ways to set the rbenv version".

https://github.com/rbenv/rbenv#choosing-the-ruby-version

The rbenv segment should likely be improved to account for all of those use cases.

[MatthewMDavis]

Yes. rbenv lets you do the following:

global: you can run system ruby, or any of the rubies you've installed with
ruby-build, as the program that runs when you type "ruby" from anywhere on
the system ("rbenv global"). This is stored in a .ruby-version file in the
RBENV_ROOT.

local: you can run system ruby, or any of the rubies you've installed with
ruby-build, to run within a directory -- making it perfect for situations
where dependencies cause you to use an out-of-date ruby on a project
("rbenv local"). This is stored in a .ruby-version file in the local
directory.

shell: you can run the aforementioned rubies specific to the shell. This
sets the RBENV_VERSION variable, which is what the segment tests for now.
shell-specific setting trumps local, which trumps global.

So as it stands, if I'm in a directory where I have a local version set,
and outside of that directory I've got a global version set, the segment
doesn't know about them.

I'm happy to submit some additional logic to grab the rbenv information for
these other use cases. I've not submitted a pull request before, so you'd
need to tell me what to do.

On Fri, Feb 12, 2016 at 11:57 AM, Nate McCurdy notifications@github.com
wrote:

@MatthewMDavis https://github.com/MatthewMDavis Hi, I'm the one who
wrote the original rbenv segment, so maybe I can help.
Firstly, I wrote the segment for my use-case (which I think is pretty
standard based on what I've seen online), so if you use rbenv differently
from me, you may likely not be seeing the info you want.

My Usage
I use rbenv on my Mac when I want to test writing Ruby code in different
versions than my system Ruby. To do that, I run rbenv shell <some_version>
which creates an environmental variable $RBENV_VERSION whose value is the
version of Ruby that rbenv is currently using.

When I stop testing, I run rbenv shell --unset which resets the version
of Ruby being used to system Ruby. In that process, the environmental
variable is unset.

Here's a screenshot that shows that process:
[image: rbenv]
https://cloud.githubusercontent.com/assets/10200384/13018571/20ba4b92-d17f-11e5-8c9d-9895013ca8fd.png

I really only wanted to be notified when I was using a Ruby version other
than system Ruby. Hence why I made the segment check for the value of
$RBENV_VERSION.

Also, you mentioned a local rbenv version... I am, admittedly, not 100%
versed on the usage of `rbenv. Does that mean that there can be directory
that has it's own ruby version set? Like with a dotfile or something?

—
Reply to this email directly or view it on GitHub
#215 (comment)
.

[dritter]

I've not submitted a pull request before, so you'd need to tell me what to do.

Nothing easier than that:

1. fork the project (button on the top right)
2. clone it to your local machine
3. make your changes, push it
4. on the project page there should appear a new button "compare"

Github has excellent guides for creating and using a pull request.

[dritter]

@MatthewMDavis I forgot to mention, that we develop on the branch next. ;)

[MatthewMDavis]

I had already forked/cloned/patched/pushed the change on master before I
found the note to make a pull request to next. If I need to repeat, let me
know.

Now the rbenv segment picks up the user's current ruby version regardless
of where/how it's set.

On Fri, Feb 12, 2016 at 1:11 PM, Dominik Ritter notifications@github.com
wrote:

@MatthewMDavis https://github.com/MatthewMDavis I forgot to mention,
that we develop on the branch next. ;)

—
Reply to this email directly or view it on GitHub
#215 (comment)
.

[natemccurdy]

@dritter Just for clarity, here's @MatthewMDavis 's patch: MatthewMDavis@96a8408

It's a fairly simple patch, and gets the job done; however, I think there could be some improvements:

• Shelling out to rbenv version-name adds some overhead each time the prompt is redrawn. Not sure what to do about that.
• I personally, would like to not see anything in the rbenv segment if I'm using system ruby. I'd only want to be notified if I am using a Ruby that is different from system. Maybe adding a conditional exception for system would be an easy way around that.

[natemccurdy]

@MatthewMDavis A fix for this issue has been merged into the next branch as of PR #216 .

Feel free to check out the latest version of the next branch and give it a try.

[MatthewMDavis]

Nice. After trying out a few powerline approaches for my tmux/zsh/vim
stack, powerline9K is definitely the go-to solution for the zsh bit.

Incidentally, Nate, I share your concern about piling on overhead to redraw
the prompt: my patch cobbled together a couple of different rbenv status
components (found within oh-my-zsh themes). The method I picked for getting
the rbenv name is actually the cheaper of the two (the other guy took the
output of 'rbenv version' and ran it through a sed filter, using two shell
processes to do the work we did in one). When I first discovered that you
were using an ENV variable instead, I was hopeful that you had found the
cheapest way of all. But as we've discovered, the ENV solution only solves
one use case.

On Sat, Feb 20, 2016 at 8:33 PM, Nate McCurdy notifications@github.com
wrote:

@MatthewMDavis https://github.com/MatthewMDavis A fix for this issue
has been merged into the next branch as of PR #216
#216 .

Feel free to check out the latest version of the next branch and give it a
try.``

—
Reply to this email directly or view it on GitHub
#215 (comment)
.

[bhilburn]

@MatthewMDavis @natemccurdy - What is your opinion regarding the state of this bug, then. Are there additional steps that we should take immediately to improve Ruby handling, or open questions?