Benoit Daloze

This seems a pretty big bug to me with high potential for confusion and very hard to find out what's going on. In fact there are now 2 more issues...

I have been using `BUNDLE_PATH: "vendor/bundle"` (via `bundle config --global path vendor/bundle `) for a long time and it works well. One issue I saw is when running a default...

> if `.bundle` is cached (e.g. in ruby/setup-ruby, in CI, etc). Actually I think this is a pretty major concern against using `.bundle`. E.g. if a CI system caches `.bundle`...

Yeah, that would work too. `default_install_uses_path` already exists and according to docs uses `.bundle` though. To make my concern concrete, it seems the GitHub cache package doesn't have a way...

Please see this comment regarding `--env-shebang`: https://github.com/rubygems/rubygems/pull/2847#issuecomment-661041263 Quoting here: `--env-shebang` is not enough to share executables from all Rubies, because it currently uses the launcher name and not always just...

What if `Prism::Translation::Parser` was like `Parser::CurrentRuby`, i.e. use the syntax version based on RUBY_VERSION?

Ah OK, I missed `Prism::Translation::ParserCurrent` then agreed deprecating/removing seems best.

Maybe it should `Prism::Translation::ParserLatest` or so to be more explicit? `Prism::Translation::Parser` from the name is pretty ambiguous, I would also assume it uses the current Ruby version for syntax version,...

Thanks for writing up the proposal. I don't know how often this is useful, for example if it's a `ThreadLocalVar` which can be stored e.g. in a constant/globally there is...

Given this seems mostly convenience on top of `ThreadLocalVar` to be a bit shorter (e.g. `tvar`/`self.tvar = v` vs `@tvar.value`/`@tvar.value = v`), I think it's best as its own gem....