Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ruby_install definition breaking on El Capitan #6

Open
mjstallard opened this issue May 3, 2016 · 3 comments
Open

ruby_install definition breaking on El Capitan #6

mjstallard opened this issue May 3, 2016 · 3 comments

Comments

@mjstallard
Copy link

mjstallard commented May 3, 2016

Hello!

We're just trying to use sprout wrap on a clean build of El Capitan, and we're seeing a strange issue. During the sprout_base_bash_it_enable_feature action, we get a failure due to the ruby_install definition in sprout-rbenv being unable to complete as it cannot write to the /Library/Ruby/Gems/2.0.0 directory.

We can do a temporary workaround by issuing:

sudo chown -R pivotal:staff /Library/Ruby

...but that feels wrong to us.

Please find below the output of running soloist:

soloist_output.txt
ruby-build_output.txt

We are using the latest Pivotal machine image, which appears to be a pretty bare-bones El Capitan 10.11.4. System Integrity Protection is enabled.

Thanks! 😄

Mike and Heather

@wendorf
Copy link
Member

wendorf commented May 5, 2016

Hi @mjstallard ,

Looking at the output, rubygems for Ruby 2.2.3 believes that your gem_home is the Ruby 2.0.0 gem home. The logic for finding the gem_home is here (possibly an older commit, though). A sudo will get you past the error, but doesn't fix the underlying problem, since your 2.2.3 Ruby won't have its default gems installed.

It would be really helpful if you could look at the gem_home logic and compare it to your system state to see why it's getting the system Ruby location instead of the newly-installed Ruby. Possibly due to overriding environment variables?

My suspicion is that rbenv is not playing nicely with getting called from within a bundle exec of soloist. The bundle exec may be setting environment variables that rbenv is not sufficiently overriding.

If you're having trouble tracking down the exact issue, another interesting experiment would be to install the same rubies using pivotal-sprout/sprout-chruby. That would at least narrow down the cause.

@mjstallard
Copy link
Author

mjstallard commented May 5, 2016

Update - so we switched out the references to sprout-rbenv and rbenv from the soloistrc, and replaced them with sprout-chruby and everything worked just fine from a clean install.

@wendorf
Copy link
Member

wendorf commented May 16, 2016

This feels like an issue that may be fixed by improvements to sprout-base's PATH manipulation. Worth investigating.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants