Add ability to specify "rvmrc" as rvm_ruby_string #4

Merged
merged 4 commits into from May 22, 2012

Projects

None yet

3 participants

@gucki
gucki commented Apr 3, 2012

No description provided.

@mpapis mpapis and 1 other commented on an outdated diff Apr 3, 2012
lib/rvm/capistrano.rb
shell = "rvm_path=#{rvm_path} #{shell} --path '#{release_path}'"
+ when "rvmrc"
+ ruby = File.read('.rvmrc').gsub(/^rvm\s+/, "").strip
@mpapis
mpapis Apr 3, 2012 RVM member

did I understood this correctly - read the file and assume it contains only:

rvm 1.9.3

This is unfortunate assumption as there can be a lot more, better approach would be:

ruby=`rvm rvmrc load . >/dev/null; rvm current`

but this goes to be equal to current ruby:

set :rvm_ruby_string, ENV['GEM_HOME'].gsub(/.*\//,"")

which could be extracted to:

set :rvm_ruby_string, :local

and :local => ENV['GEM_HOME'].gsub(/.*\//,"")

@gucki
gucki Apr 3, 2012

Yes - sorry, didn't really know it can contain much more - never used it for that.

Lets then use your proposal with naming it "local" and using the ENV. :)

Shall I update the pull request accordingly?

@mpapis
mpapis Apr 3, 2012 RVM member

yes, please, do you think anyone will want to deploy application from different ruby/gemset then the strored in .rvmrc - or other from the new project file formats ? -> https://rvm.beginrescueend.com/workflow/projects/#ruby-versions

@gucki
gucki May 22, 2012

I never used gemsets as I always use bundler. I think there's no reason and it's bad pratice to use a different ruby locally than remote and hope nobody does it. So I think we don't have to take this into account.

@mpapis mpapis was assigned Apr 3, 2012
@mpapis
Member
mpapis commented May 14, 2012

@gucki any progress on updating the pull request?

@Mange
Mange commented May 16, 2012

/me subscribing

@gucki
gucki commented May 22, 2012

Sorry for the long delay - it's finally updated :)

@mpapis
Member
mpapis commented May 22, 2012

looks good, i was thinking on safeguards to protect from empty GEM_HOME/ruby would it be possible ?

@gucki
gucki commented May 22, 2012

It's safe guarded now :)

@mpapis mpapis merged commit 99fa47b into rvm:master May 22, 2012
@mpapis
Member
mpapis commented May 22, 2012

@gucki it's perfect, thank you very much! <3

I will release rvm-capistrano 1.2.1 a bit later today.

@mpapis
Member
mpapis commented May 22, 2012

1.2.1 is released

@gucki
gucki commented May 22, 2012

Great, thanks! :)

@gucki
gucki commented May 23, 2012

I just hit some (minor) problem: even inside a small team it seems likely that different patch levels of the same ruby are used. The same is true for the production system. But right now we supply the full ruby version including the patch level, which makes it impossible to deploy from a system using ruby-1.9.3-p194 on a server using ruby-1.9.3-p125.

I'd like to supply another patch/ pull request which removes the patch level from the ruby string to be used. Something like gsub(/-p\d+$/, ""). What do you think?

@Mange
Mange commented May 23, 2012

@gucki I would recommend your team to explicitly specify the patchlevel in your .rvmrc files. Patchlevel releases differ more than most people know.

@gucki
gucki commented May 23, 2012

It's not an easy task to make sure that server uses the same patchlevel as all the devs. And I've never had any problems switching from one patch level to another. Even heroku says http://blog.heroku.com/archives/2012/5/9/multiple_ruby_version_support_on_heroku/:

While you can specify the version of Ruby for you app, you can't specify a patch version, such as Ruby 1.9.2-p290. Ruby patches often include important bug and security fixes and are extremely compatible. Heroku will provide the most secure patch level of whatever minor version number you request.

@Mange
Mange commented May 23, 2012

...and certain patchlevels of Ruby 1.8.7 broke the MongoDB drivers, for example.

These things happen, and I still think it makes sense that :local means just that. If you just want some general version number, like 1.9.3, how hard is it to just write it out in the deployment recipes?

I was sure that this change was to make it easier for people that do specify patchlevel as they wouldn't have to duplicate this in both deploy.rb and in .rvmrc.

@mpapis
Member
mpapis commented May 23, 2012

the problem with .rvmrc is that it does not provide a format that can be used to read it and detect if user want's 1.9.3 or 1.9.3-p125 --- this could be done with the other formats which require ruby version to be specified in only one way - which is predictable and could be used to read the required version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment