Problems installing Compass (conflicting Ruby versions?)

[cibulka]

Hello and thanks again for awesome development stacks!

My situation: I am struggling to install Compass to my virtual machine (although everything else works perfectly and out of the box). After intense debugging, it seems that the problem lies in conflicting Ruby versions according to ouput of gem env on fresh enviroment (that is, provisioned only from Ansible scripts made by you):

RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.23
  - RUBY VERSION: 1.9.3 (2013-11-22 patchlevel 484) [x86_64-linux]
  - INSTALLATION DIRECTORY: /var/lib/gems/1.9.1
  - RUBY EXECUTABLE: /usr/bin/ruby1.9.1
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
  - ruby
  - x86_64-linux
  - GEM PATHS:
  - /var/lib/gems/1.9.1
  - /home/vagrant/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
  - :update_sources => true
  - :verbose => true
  - :benchmark => false
  - :backtrace => false
  - :bulk_threshold => 1000
  - REMOTE SOURCES:
  - http://rubygems.org/

See Ruby version (1.9.3) vs Ruby executable (1.9.1) etc.? Compass error: You don't have /root/.gem/ruby/1.9.1/bin in your PATH, gem executables will not run. (...) Gem files will remain installed in /root/.gem/ruby/1.9.1/gems/ffi-1.9.3 for inspection. Results logged to /root/.gem/ruby/1.9.1/gems/ffi-1.9.3/ext/ffi_c/gem_make.out.

And finally, to my question

1. Is there any existing Ansible setup of Grunt / Bower / Compass installation that is known to work in the Bedrock-Ansible stack?
2. If not, is it possible to replace roots/bedrock-ansible box with some more common one (like hashicorp/precise64) that has those setups available?

I can provide much more information about my errors, however they are a little hard to narrow down. However if it would help, I will definitely try to.

Thanks!

[cibulka]

OK, switching boxes from roots/bedrock-ansible to hashicorp/precise64 seems to work for me (although everything seems to be significantly slower).

Also, even on hashicorp/precise64 I can install Ruby gems by a method mentioned in this SO answer: http://stackoverflow.com/questions/22115936/install-bundler-gem-using-ansible

The problem is that, when running gem install bundler via ansible, you're not initializing rbenv properly, since rbenv init is run in .bashrc or .bash_profile. So the gem command used is the system one, not the one installed as a rbenv shim. So whenever you install a gem, it is installed system-wide, not in your rbenv environment.

Example Ansible role:

- name: Install Bundler
  command: bash -lc "gem install bundler"

If there was a way how to resolve Ruby conflict (if the problem with Compass is there) and get back from precise64 to roots/bedrock as it's ...

1. very fast
2. an official box to use with your awesome stack

... it would be rad.

[swalkinshaw]

Few things:

1. This Ansible playbook doesn't do anything to Ruby. Whatever comes standard with Ubuntu is there. Which is version 1.9.3.
2. Pretty much any solution to installing Ruby will tell you to use rbenv (or rvm) because of problems like you had. Without those you need to install gems globally and it leads to problems.
3. The difference between hashicorp/precise64 and roots/bedrock boxes may just be that our base box has recently updated/upgraded all packages through apt-get upgrade and apt-get dist-upgrade.

You should probably just look into using an existing rbenv role like:

• https://github.com/zzet/ansible-rbenv-role
• https://github.com/leucos/ansible-rbenv-playbook

[cibulka]

Thanks for quick response! I will definitely take a look at rbenv playlists.

One last thing - Would you maybe consider to add Grunt & Compass Ansible role to Roots/Bedrock-Ansible with recommended Ruby setup? It seems, that other project of yours are quite Grunt-oriented, so I would guess that majority of your users would appreciate that. And all server noobs like I am would be spared from the multiple Rubies arcane! :)

[swalkinshaw]

This playbook is supposed to be Bedrock specific, but not Roots. So I'd rather not add things unless required. Although it might grow into needing these things so we'll see.

[cibulka]

If your approach is to keep things simple and not adding anything not-required, what about to just include RBENV/RVM for us and normalize the Ruby enviroment? One thing I loved about Bedrock-Ansible was the fact it worked straight out of the box. It would be nice, if same thing would apply for gem installation by Ansible ...

[swalkinshaw]

It still does work straight out of the box for its intended default use case. How would adding a specialized Ruby role keep things simple? Especially when it wouldn't even be used by default.

I understand this would make things easier for you, but just imagine if we added a role for everything someone wanted by default.

[cibulka]

Okay, I get how adding optional Grunt/Compass installation to the stack is too localized. But errors happening after (only some, not all) gem installs otherwise fully supported by Ansible due to conflicting versions of Ruby sound like a bug to me. Or at least unexpected behaviour for the user. Even more so, if the problem is "fixed" by replacing roots/bedrock-ansible box with default hashicorp/precise64.

If all of that is easily fixable by some sort of package, that resolves which Ruby is used when (and which one is used by default), is sounds to me like a win-win for everyone.

But then again, I really don't know much about LAMP dependency management and Ruby, so maybe this really is an unreasonable request ...

[swalkinshaw]

I'd be interested to know if you would run into the same issue with hashicorp/precise64 after running apt-get upgrade and apt-get dist-upgrade. Nothing else we're doing should be messing with Ruby packages.

[cibulka]

Right now I need to finally focus on actual development and not potentially blowing up my local enviroment (again) :), but once I'll have some time in my hands, I will try to do that and let you know!

[austinpray]

As I understand the default way to handle a bedrock full stack:

• You have your host system, this is whatever physical computer you have in front of you.
• Bedrock-ansible provisions the environments your site runs in. Dev, Test, Prod, etc.
• Bedrock provides an opinionated default wordpress scaffold.
• Roots is a base theme (this is where grunt/gulp and compass are relevant).

Technically you can have three different repositories for a project:

• trendysite.io repos
  • trendysite-bedrock-ansible
  • trendysite-bedrock
  • trendysite-roots

Where trendysite-bedrock has trendysite-roots symlinked, git-submoduled, etc. I usually do not get this fancy (separating bedrock from roots). However, it can be very advantageous for people working on teams to be able to divide their effort into ops, backend, and theming. Separation of concerns. It also becomes advantageous when you want to update your bedrock-ansible or bedrock setup from the upstream master.

bedrock-ansible and bedrock do not really have much to do with the theme's build process. The theme is built by the host machine. Say you built a theme from scratch and it's dependencies were like Ruby 2+ and Node 0.11 because you have some super strange build process. It is the responsibility of the host machine to have these dependencies. You could make ansible provision the vagrant VM to have the build dependencies but I personally would rather have the full power of my host machine with no VM imposed overhead slowing down my build.

So all in all, installing ruby and node seems out of scope for bedrock-ansible, as it's job is to just be the best LEMP server provisioner possible. It should not care what type of build process you are using and what the dependencies are.

If you want to have very consistent builds among a large group of developers (seems really excessive and unlikely for wordpress of all things), set up a CI server and have that run all the builds that make it to production.

@swalkinshaw does all that sound correct? This is how I understand things after working with this for a while.

[swalkinshaw]

@austinpray more or less. Maybe a few points of clarification:

1. If you were to have your themes (Roots for example) as a separate repo, might as well make it a Composer package (with a type of wordpress-theme) and manage it through that.
2. I don't blame @cibulka for wanting Ruby installed on the remote server. By default Bedrock uses Capistrano which is set up to run all build processes on the server during deploy. Cap doesn't easily let you build/compile things locally and then transfer. Example solution for doing it locally: https://gist.github.com/nateroling/22b51c0cfbe210b00698

[austinpray]

If you were to have your themes (Roots for example) as a separate repo, might as well make it a Composer package (with a type of wordpress-theme) and manage it through that.

I want to learn more about how this is done. Perhaps I will make a thread over on the roots forum.

I don't blame @cibulka for wanting Ruby installed on the remote server. By default Bedrock uses Capistrano which is set up to run all build processes on the server during deploy.

Well yes because Capistrano was built originally for working with ruby on rails where ruby is the only dependency and all the assets are compiled via asset pipeline. If you want to use bower with rails you pretty much are stuck checking files into source control or using the gist you described. Same exact situation.

https://gist.github.com/nateroling/22b51c0cfbe210b00698

Yeah this is exactly what I do in order to avoid checking assets into version control. Wish I knew about this gist when I wrote that feature.