Skip to content
This repository has been archived by the owner on Jun 25, 2020. It is now read-only.

Ruby version managers #36

Closed
ysbaddaden opened this issue Jul 29, 2013 · 7 comments
Closed

Ruby version managers #36

ysbaddaden opened this issue Jul 29, 2013 · 7 comments

Comments

@ysbaddaden
Copy link
Owner

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.

@ysbaddaden
Copy link
Owner Author

See #23 and #25 for rbenv, #30 for RVM, and #35 #34 for chruby.

@ysbaddaden
Copy link
Owner Author

As @davekaro suggested, Pow uses .powenv for environment variables, and sources .powrc in your application directory, thus allowing to select a ruby version: http://pow.cx/manual.html#section_2.2

But a per project configuration looks quite cumbersome.

@ysbaddaden
Copy link
Owner Author

Reading the doc for Process.spawn, maybe the following could do the job, assuming that Racker will load either .praxrc in the app folder, then defaulting to ~/.praxconfig if .praxrc can't be found.

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
)

ysbaddaden added a commit that referenced this issue Jul 29, 2013
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.
@jneen
Copy link
Contributor

jneen commented Oct 10, 2013

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?

@mpapis
Copy link

mpapis commented Nov 25, 2014

here is dynamic code that loads proper ruby via RVM in Pow: https://rvm.io/integration/pow
for static variables use:

rvm env > .paxrc

@jneen
Copy link
Contributor

jneen commented Nov 25, 2014

nice! so for ry it'd be

ry setup $MY_RUBY > .praxrc

@ysbaddaden
Copy link
Owner Author

I updated the Ruby Version Manager with page with your snippets.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants