rvm head (after 1.8.6): new set/alias behavior

[ryansch]

See rvm/rvm#494

rvm 1.9.0 will support the following syntax:

# rvm [ruby] do something :
rvm default do something
rvm default@gemset do something
rvm /path/to/project do something
rvm default@gemset

rvm use /path/to/project

rvm install ruby-named ; rvm use ruby-named

I ran into this not working in 1.8.6 when trying to use rvm_gem without specifying the ruby_string. It defaults to 'default' which fails horribly on both 1.6.5 and 1.8.6.

I have a local patch to the cookbook that can resolve 'default' to ruby@gemset. Are you interested in seeing it or should we just rely on this new functionality?

[ryansch]

I'm also excited to replace my existing .rvmrc parsing with the new set behavior that can rely on the project directory.

[ryansch]

I can confirm that 'default' is now handled correctly as of rvm/rvm@8edf22c

[ryansch]

It looks like the rvm guys are even trying to make it so you can rvm use /path/to/project-with-rvmrc. Maybe we can just kill the normalize ruby string stuff in the cookbook?

I still have issues with rvm_shell, rvm_gem if I don't specify a ruby_string. It defaults to 'default' but doesn't grab the gemset when it normalizes.

Edit: I can see from my own submission above that they've been planning to do this for 1.9. Somehow I just noticed.

[fnichol]

I think I 70% understand what you mean. Does this still not execute properly for you (i.e. dropping the @gemset)? If you have a reference to your local patch it couldn't hurt to see.

Do you think an unset/nil rvm_string attribute value should fallback to node['rvm']['default_ruby'] instead? That might help improve Principle of Least Surprise since it could include a gemset.

Anyway, not ignoring this one, just getting my head around it :)

[ryansch]

I've decided my patch is a bit too buggy. It introduced some weird edge cases I was hitting my head on.

I think we have 2 options:

1. Now that rvm can resolve aliases, project directories, etc, we should change our normalization strategy to lean on what rvm is doing.
2. Change the default for unset ruby_strings across the board to be node[:rvm][:default_ruby].

[ryansch]

The other use case I'd really like to see is this:

rvm_wrapper 'project' do
  project_dir "/path/to/project"
  binary 'rake'
end

rvm_shell 'bundle install' do
  project_dir "/path/to/project"
  code <<-EOS
  bundle install --without test development --local
  EOS
end

With rvm_wrapper, it could still be called ruby_string. With rvm_shell I was thinking it would also set the cwd to the project dir.

Now that rvm will let you target a project directory as if it were a ruby string this shouldn't be too hard. I took a first look at how I'd implement this but was again hitting my head on what we should do about ruby_string normalization.

[martinisoft]

Hi @ryansch

I realize its been a while since this discussion, but would you want to submit or have already submitted a PR to include this functionality? If not then I'll close this down to clean up outstanding tickets.

[ryansch]

@martinisoft I don't use rvm on my servers at this point. I've moved on to rbenv due to all the issues I was having. Thanks!

[martinisoft]

@ryansch sorry to hear that, but thank you for responding.

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