Problems installing Compass (conflicting Ruby versions?) about trellis HOT 12 CLOSED

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.

from trellis.

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

from trellis.

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! :)

from trellis.

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.

from trellis.

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 ...

from trellis.

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.

from trellis.

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 ...

from trellis.

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.

from trellis.

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!

from trellis.

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.

from trellis.

@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

from trellis.

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.

from trellis.