Rubinius does not install gems binary in $PREFIX/bin and so bundle and pry are not available

[eregon]

Rubinius does not install gems binary in $PREFIX/bin and so bundle and pry are not available

[brixen]

@eregon chruby works fine with Rubinius, as far as I know, and it's extremely light and interoperates well with other env changers, so that's an option.

What would Rubinius change to accommodate what you're asking for? (I'm not entirely clear). Rubinius very long ago made a number of decisions to avoid conflicting with MRI. If you want to propose a PR, it would probably help evaluate what you're trying to achieve in concrete terms.

[brixen]

@eregon the approach I'm going to take for Ruby switchers is to include code in Rubinius that sets them up correctly, instead of relying on the switchers to do it. Not sure when I'll get around to writing that code, though.

Since I intend Rubinius to be installed parallel to MRI without interfering with it, I won't support installing into dirs that would clash with the installed Ruby.

[eregon]

Basically this choice means Ruby switchers need code specifically for Rubinius, otherwise it would be as simple as adding ruby_prefix/bin to PATH and be done.
They already have this code (mentioned in postmodern/chruby#410 (comment)), but I find it unfortunate complexity.

Also, it's clearly less convenient (need rbx -S all the time) if people want to use Rubinius without a version switcher. Other Rubies would just need adding prefix/bin to PATH.

Since I intend Rubinius to be installed parallel to MRI without interfering with it

I personally think this is a bad idea and very likely to go wrong if e.g., a Rubinius process shells out to say, rake or rspec as it will then pick MRI instead of Rubinius. But it's your choice, I won't argue more here.

[brixen]

@eregon I'm not trying to argue with you about it. It's a simple constraint problem. I understand that you want personal convenience, but

1. You're unwilling to use a Ruby switcher;
2. You're unwilling to add to your PATH;
3. You haven't offered any other solution for not clashing with MRI.

The constraint that I have to solve for is not clashing with MRI. This is a distribution issue for Rubinius because MRI is the incumbent, and I intend for Rubinius to be used far beyond Ruby, too. So I need a solution that meets this constraint.

I've offered to write specific code inside Rubinius just to accommodate the various Ruby switchers to make it as easy as possible to both get Rubinius (considering the vast array of packaging systems out there) and to use Rubinius without conflicting with MRI.

Perhaps defining a shell alias would help your personal case.

[eregon]

FWIW, I'm willing to add to PATH, but only rubinius-prefix/bin, not anything else. That's what the issue above is about: Rubinius needs two executable directories in PATH when all other Rubies only need one.

Re 3., I think just adding rubinius-prefix/bin to PATH should be enough, and one could still have rbx as a symlink globally available (as that one is never conflicting).

BTW in Rubinius 4.5, the erb, gem, irb, rake, rdoc, ri, ruby and testrb all clash with MRI executables.

[brixen]

@eregon ok, thanks for pointing out those clash, I'll try to get that addressed soon.

Am I understanding correctly that as long as all Rubinius executables (including rbx) install to a single non-system directory that wouldn't clash with MRI, that would work for your case?

[eregon]

Am I understanding correctly that as long as all Rubinius executables (including rbx) install to a single non-system directory that wouldn't clash with MRI, that would work for your case?

I'd want the opposite, a single directory with rbx, gem and all gem executables, and it should be prefix/bin for compatibility with other implementations.
There could be some other directory with just rbx that can then be used to avoid clashes if desired.