-
Notifications
You must be signed in to change notification settings - Fork 49
Ruby version managers #36
Comments
As @davekaro suggested, Pow uses But a per project configuration looks quite cumbersome. |
Reading the doc for Process.spawn, maybe the following could do the job, assuming that Racker will load either args = if gemfile?
[' bundle', 'exec']
else
['ruby']
end << [racker_path, '--server', socket_path]
# are there any required environment vars to keep/set?
env = { 'PATH' => ENV['ORIG_PATH'] }
pid = Process.spawn(env, *args,
:chdir => realpath,
:out => [log_path, 'a'],
:err => [:child, :out],
:unsetenv_others => true,
:close_others => true
) |
This is an attempt at skipping support for specific version managers as per #36, while still permitting the user to choose the ruby version under which racker must run. It works by changing the call to Process.spawn to a string instead of a list of argument, which forces the command to be run through a shell and not directly from the ruby process. We also clean the environment from everything except for PATH which is set to ORIG_PATH, which is the PATH before Prax is started, thus skipping any ruby version changes. It works perfectly with rbenv.
Hey there, I'm the author of ry. What would you suggest as a way to make it more friendly to this sort of launching? |
here is dynamic code that loads proper ruby via RVM in Pow: https://rvm.io/integration/pow rvm env > .paxrc |
nice! so for ry it'd be ry setup $MY_RUBY > .praxrc |
I updated the Ruby Version Manager with page with your snippets. |
There is a problem with having Prax written in Ruby while using a ruby version manager (like rbenv, rvm, chruby or ry).
Prax is a ruby process, running one version of ruby (say 2.0.0-p247) that spawns other ruby processes which sometimes require a specific ruby version or engine (say jruby-1.7.4). A per-project version can be selected uniformly with a
.ruby-version
file in your project folder.One would think that version managers will take care of that, but they don't. They modify the PATH, so the correct gems are loaded for each ruby version, and they may set some environment variables to somehow for the selected ruby version —rbenv sets RUBY_VERSION.
So, version managers are getting in the way. How to fix that once and for all?
I initially fixed rbenv because this is the one I use. I recently got a patch for RVM that does RVM's job by loading the
.ruby-version
and forcing RVM to use that version, and one for chruby that does the same thing. We're only missing a patch for ry —others are deprecated in favor of chruby.But I don't like this idea of doing the version manager's job. I'd like a fresh shell environment, cleaned from the selected ruby version, so that the version managers would do their job: select and run the ruby version that the user wants when I run ruby in a project with a
.ruby-version
file.Is that possible? A fresh shell environment, coupled with the existing and sourceable
~/.praxconfig
where any local configuration could happen.The text was updated successfully, but these errors were encountered: