support gems and binstubs in locations commonly used by gem and bundler
while coming from chruby with frustration i tried fry with fun but had to revert back to my direnv script due to the lack of support for the above. or am i missing something?
part of my .direvnrc:
rb_version="2.3.1"
use_ruby() {
local ruby_ver=$1
local ruby_dir=$HOME/.rubies/ruby-$ruby_ver
local gem_dir=$HOME/.gem/ruby/$ruby_ver
export GEM_HOME="$gem_dir"
export GEM_PATH="$gem_dir"
export BUNDLE_BIN="$ruby_dir/bin"
path_add MANPATH "$ruby_dir/share/man"
PATH_add "$HOME/.rubies/ruby-$ruby_ver/bin"
PATH_add "$GEM_HOME/bin"
PATH_add "$BUNDLE_BIN"
}
if [ -f ".ruby-version" ]; then
use ruby "$(cat .ruby-version)"
else
use ruby $rb_version
fi
if [ -n "$GEM_HOME" ]; then
echo "ruby gems at: $GEM_HOME"
fi
while it works well and is kinda POSIX portable i'd still prefer something fishy because i use that shell heavily.
another thought is that bloating up fry might not be good so i'll consider https://github.com/jamesob/desk as it kinda closely resembles direnv.
What is not working? fry is only adding the ruby bin path to the beginning of the PATH. That is where my ruby binaries gets added. I have had local binstubs generated by bundler, but then I had another script that prefixed that to the PATH. Which part specifically are you missing? Having the $GEM_HOME/bin in path? Or setting some environment variables that are not PATH?
sorry, well, maybe i was just expecting that fry is comparable in features to chruby and similar. i dont have any other script that does that - except what i posted above, which is meant to be used exclusively, not in combination with something.
for me, switching ruby version ist pointless as long as i can only have a global gemspace. i need to have seperation, and this is what the above script does - setting GEM_HOME, BUNDLE_BIN and add to PATH accordingly.
Yes, that is understandable, and I kind of agree that those things should work. Just looking at that config you have there BUNDLE_BIN is set to the same path as the ruby one. So no need to add both of them to the path. However if you are using something like project/bin for local binstubs with bundler that is a different thing. Would be quite easy to add something like that to the paths which I have done with a simple directory change hook.
I have personally not used the GEM_HOME configuration so not sure what it adds. For me most ruby versions don't install anything in the $HOME/.gem/ruby/x path.
This is why I was curious about what is not working, because I am not sure what those variables changes in terms of behaviour.
well BUNDLE_BIN might be overriden in a directory-bound .envrc while i dont have to do that often. like when hassling with some existing legacy project left behind and stuff. so that is really optional.
gem will always respect GEM_HOME. while i have messed up my global gemset so many times with some other project i decided to have it set strictly always. please note direnv might just do nothing - depends if the acutal directory is _allow_ed to have it loaded - so it might look less selective than it actually is.
reading a bit more i am unsure on how to implement that properly on the fry side. hope this discussion is still beneficial somehow 😬 if you do not mind additional complexity i consider gst worth having a look at. on the pro side, a lightweight ruby manager supporting gemsets be cool 🐟 . regards