Benoit Daloze

@dentarg Could you show `ruby -e 'p RbConfig::CONFIG["ENABLE_SHARED"]'`? Maybe it's caused by having installed a static-libruby (`ENABLE_SHARED=no`) Ruby 2.7.1 before, and the 2.7.1 Ruby being selected is a dynamic-libruby (`ENABLE_SHARED=yes`)....

It would mean a new env var (GEM_USER_DIR?), adding and removing it from PATH. I'm not sure it's worth the trouble and it seems nobody cared so far, so probably...

Yeah, it's true the risk should be limited to people using `--user-install`. I would call `Gem.user_dir` though, there is no guarantee the path will not change in future RubyGems versions.

There is also a non-trivial interaction with `GEM_HOME/GEM_PATH`, so `Gem.user_dir + "/bin"` should be only added to PATH if GEM_PATH is not set, to avoid duplicate entries in PATH.

Actually, that's more complicated than I thought, even GEM_HOME/GEM_PATH don't change the `USER INSTALLATION DIRECTORY`, which in such a case is not even part of `Gem.path` and so won't be...

That makes sense to me, indeed chruby gems could mix with `--user-install` gems of Ruby 2.x.0 and nobody wants to debug that. I think `--user-install` should be supported based on...

Proof-of-concept PR for `$CHRUBY_SET_GEM_HOME`: https://github.com/postmodern/chruby/pull/423

> The reason why chruby sets `GEM_HOME` for non-root users is to protect the ruby's built-in gem home, which may not always be writable. Right, I know. This is very...

@postmodern Any thoughts on my reply? I like the idea of detecting if GEM_HOME is writable, it sounds like a much cleaner check than "is root" or "env var", should...

@postmodern Here is a PR implementing the idea of setting GEM_HOME only if the default gem directory is not writable. It looks very elegant to me, please review it: https://github.com/postmodern/chruby/pull/431