I like the approach of using gs (simple gemsets) [1] and dep (simple dependencies) [2]. I've been using this approach of handling dependencies for a while now.
I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs", `gem install` will install them there instead of globally. All I have to remember is to create a .gs directory when I start a new project.
It does not address all issues highlighted in the article, nor do I know how well this would work in a production environment with automated deployments. It's probably more of a work around than a solution. I vastly prefer it for personal projects, though. Hate solving gem conflicts with "bundle exec".
Instead of changing environment variables when $PWD changes, I went the other way: make it obvious when you're in a subshell by strapping $VIRTUAL_ENV onto $PS1. Again, simple shell scripts win[0][1].
I'm still interested in a cross-language approach, but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree. Unless Gemfile.lock is involved, it's going to need to copy Bundler's resolution algorithm, which seems fraught.
>but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree.
The current 'guix import gem' utility doesn't do dependency resolution at all. It just generates some Scheme code for you to start with and you fill in the gaps. It's important to understand that Guix packages specify the exact versions of its dependencies. That includes not only the version number, but its explicit dependencies, the Ruby used during the build, the GCC used for native extensions, the full build script, etc. All of these various inputs to the build function are reflected in the SHA256 hash that uniquely identifies that package.
The loose versioning that Bundler uses is indeed very flawed and prone to strange errors. Guix simply doesn't have this issue.
I do something similar to this. My right prompt shows a small fork symbol when I'm in a sub-shell (based on $SHLVL). However, this does not help me much when I'm several levels deep, which is why eventually I started hooking in on changes to $PWD.
I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs", `gem install` will install them there instead of globally. All I have to remember is to create a .gs directory when I start a new project.
It does not address all issues highlighted in the article, nor do I know how well this would work in a production environment with automated deployments. It's probably more of a work around than a solution. I vastly prefer it for personal projects, though. Hate solving gem conflicts with "bundle exec".
[1]: https://github.com/soveran/gs [2]: https://github.com/cyx/dep