rbenv-init no longer works in latest rbenv.

[robharrop]

With issue rbenv/rbenv#254, the rbenv-init script now calls rbenv-commands directly rather than rbenv commands.

As such, the recipe should really call rbenv init - to make sure the correct path setup happens.

[mislav]

How does it not work?

Calling rbenv-commands internally from rbenv will always work because rbenv ensures "libexec" is on the path at runtime.

I just tested it out a little bit more and it works for me. I'm always using edge rbenv, so I would spot the breakage myself if there is some.

[sstephenson]

More info here: rbenv/rbenv#293 (comment)

The Chef recipe should always use unhyphenated commands, e.g. rbenv init instead of rbenv-init.

[meineerde]

I can reproduce the issue here. I'm not fully sure on why it happens.

================================================================================
Error executing action `run` on resource 'bash[Initialize rbenv (system)]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '127'
---- Begin output of "bash"  "/tmp/chef-script20121213-28841-19acx5e-0" ----
STDOUT: export PATH="/usr/local/rbenv/shims:${PATH}"
source "/usr/local/rbenv/libexec/../completions/rbenv.bash"
rbenv rehash 2>/dev/null
STDERR: /usr/local/rbenv/libexec/rbenv-init: line 85: rbenv-commands: command not found
---- End output of "bash"  "/tmp/chef-script20121213-28841-19acx5e-0" ----
Ran "bash"  "/tmp/chef-script20121213-28841-19acx5e-0" returned 127

The full stacktrace is at https://gist.github.com/4277134

[meineerde]

It might be caused by the initial run not being on top of an rbenv ruby but the system ruby...

[mhoran]

Fixed in #26.

[fnichol]

Ha, looking at my code there I don't even recognize it :) After working with sub for the last 2 weeks, I wouldn't have invoked init that way had I wrote it today. Pulls in #26

[axelson]

#26 fixes it for me as well. Would it be possible for chef-rbenv to not always depend on the latest rbenv to help prevent these breakages in the future?

To be clear I'm talking about the attributes file:
https://github.com/fnichol/chef-rbenv/blob/master/attributes/default.rb#L24

[fnichol]

@axelson You're right about that: everyone should be pinning the version of rbenv they want installed. Maybe the default value of "master" is misleading--I always pin a version here that isn't master.

In my mind we could go two other ways:

• Leave the value empty and deal with the consequences
• Set the last stable release tag as the value (currently "v0.3.0") and leave it to the cookbook user to update if needed

Thoughts?

[axelson]

My vote is number 2 so that chef-rbenv will work by default (important so that it can easily be used in things like rails-last-mile).

[mhoran]

My vote is leaving it on master and making it clear to users that they should pin the version. I think it's better to install the latest and deal with possible instability than install an old version that will be pinned at an arbitrary version (0.3.0 doesn't work for me for some reason.)

[mislav]

Hi, maintainer of rbenv here.

My suggestion is to pin it to the latest git version that you've confirmed this recipe to work, i.e. the current HEAD sha, but leave an option to users to pick their own sha/tag/branch to install.

Most users won't pick their own, so they should get a version which is known to work well with the recipe. But don't set to v0.3.0 which has some bugs that we fixed in master recently.

[fnichol]

@mislav Thanks for chiming in! If I understand correctly, you're suggesting leaving the ref at "master"?

I'm working on some continuous cookbook integration testing that may catch issues like this in the future. It's a slow grind, but getting there.

[fnichol]

As I believe we have the original issue fixed in #26, I'm going to close this ticket out. Please don't take that as a sign I want to stop talking about default['rbenv']['git_ref'] = "master" though 😄

[meineerde]

@fnichol If I correctly understood @mislav, he suggested setting a hard SHA instead of the soft branch, i.e. to set 1ebcbd92e2d28a9ade5174b7a22a9f3d7d9f3e71 as the ref (which is the current master HEAD).

[mislav]

@meineerde Yep. /cc @fnichol

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.