Ruby 2.0

[fringley]

I have a new Rails project using ruby 2.0 which is defined in the Gemfile. On our bennett machine we have RVM installed with 1.9.3 (old projects) and also now 2.0.0 for new projects. But I think because bennett is running under 1.9.3 the shell commands it runs dont properly switch under RVM to the correct version. As a result, we get:

Your Ruby version is 1.9.3, but your Gemfile specified 2.0.0

for any build step we add (e.g. bundle exec .... or rake spec for example).

Any ideas on how we might get this to work?

[joelcogen]

Bennett should handle RVM correctly when running build, if you have a .rvmrc file in your repo. .ruby-version should work too, but I never tested it...

[fringley]

That was my impression as well, but doesnt seem to be the case.

I've tried a .rvmrc and .ruby-version in the repo, but that didn't work either. Any other ideas?

Cheers,
Chris.

[tobypinder]

Watching this thread - similar issues. We exclusively use 2.0 so I'm going to try and get Bennett working on 2.0 if it proves relatively pain free (seems to be bundling OK once I remove test and development gems as I write this).

Obviously it's far from ideal to "fork" it locally like this but I will let you know if it worked or not.

[fringley]

Good to know @tobypinder - please let me know how you get on! We now have 1.9 and 2.0 projects so this is proving frustrating!

[joelcogen]

@Systho is going to try to reproduce as he just added a 2.0 project on our instance. We'll keep you posted!

[tobypinder]

@fringley @joelcogen It seems to handle 2.0 pretty much fine. My changes may be useful or they may be a hacky mess but most will be unrelated: so far I've

• Fixed some resque config errors (old config keys)
• Moved it to Ruby 2.0
• Moved it from SQLite to Postgres to fix some concurrency stuff (although I later found a possible fix).
• Modified some HAML that was moaning at me (email related: will elaborate once I revisit my changes)

The reason I bring this up is because so far I've been randomly hacking away at it to get it working, so there may be some behaviours on my install that aren't related to anything else. I'll reverse engineer my changes and test them on feature branches: there might be some salvageable pull requests.

[fringley]

Hmm. I wonder what we are doing wrong then! We have tried specifying the ruby version in our Gemfile (we usually do it this way as it works well with Heroku and RVM locally), but I've also tried adding a .rvmrc and a .ruby-version file into the directory, but still, the first build step (bundle install) fails with the ruby version issue.

To clarify: you are building projects with 1.9 and 2.0 alongside each other on the same bennett installation?

[Systho]

I managed to reproduce most of the problems on one of our 2.0 only projects but unofrtunately I also managed to reproduce other unexpected problems also :D

Our project is using postgresql so I won't be able to work on the concurrency problem but we will make sure that it can work correctly with the most usual setup : .ruby-version file and ruby() instruction in the gemfile as long as the system is able to handle it (installing the correct ruby version and a ruby switcher on the system is out of scope )

[fringley]

@Systho that would be fantastic if it could correctly work from either the gemfile ruby version or a dot file!

[tobypinder]

@Systho I don't know if this is exactly what you are referring to, but the last bullet point of #48 indicates a fix for concurrency/lock nastiness (for PG at least). It looks harmless enough to try with other DBMSs but that's as far as my knowledge extends. I can vouch for it fixing my PG issues however.

[Systho]

The ruby version switching won't be done by Benett but by the system's ruby switcher.

• RVM is able to switch rubies based on the .ruby-version file and (with lower priority) the Gemfile
• Rbenv is able to switch rubies based on the .ruby-version file and won't probably never use the Gemfile
• Chruby is optionnally able to switch rubies based on the .ruby-version file

Therefore I think we will mimic what the system would do if you cd into the project directory before running any gem binary

[Systho]

@tobypinder I just wanted to say that I managed to reproduce more bugs that what I expected, but I'll work on them one at a time. I'll have a look at the solution proposed in #48

[joelcogen]

@Systho I don't think that's possible (or at least realistic) without rbenv installed on the build machine.
This really makes me want to move to a VM-based system, where we can offer a base VM with rbenv, rvm, all rubies, databases, etc

[Systho]

Currently I managed to have the system working with zsh and rbenv but the solution should work with other setups.

Instead of manually detecting and loading rbenv or rvn or chruby, I open a no-interactive login shell and execute the command.

This means that if your system is correctly setup, it will work. But you might encounter the same kind of problem you face with capistrano if your system is only setup for interactive shell.

Speaking of zsh, it's mostly a mater of putting the setup of rbenv in .zshenv instead of .zshrc. For bash it will be about using ~/.bash_profile, ~/.bash_login, or ~/.profile

I'll continue to make some tests in order to make sure that it works with chruby and rbenv / zsh and bash and then I will propose a PR