@indirect try again ;)

It works! Nice job. :)

While testing it out, I noticed this:

❯ gem uninstall rspec-core
Gem 'rspec-core' is not installed
❯ gem exec -g rspec-core rspec
No examples found.
❯ gem exec -g rspec-core --conservative rspec
No examples found.

1. So with exec gems installing to a different location that isn't managed by gem install and gem uninstall... how does the end user handle issues installing gems?

While testing out issues installing gems, I ran into this:

❯ gem exec -g tailwindcss-rails tailwindcss
[success output]

❯ gem exec -g tailwindcss-rails --platform x86_64-darwin tailwindcss
[building native extensions blah blah blah]
/Users/andre/.rubies/ruby-3.2.0/lib/ruby/site_ruby/3.2.0/rubygems/dependency.rb:314:in `to_specs': Could not find 'mini_portile2' (~> 2.8.0) among 252 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/Users/andre/.gem/ruby/3.2.0:/Users/andre/.rubies/ruby-3.2.0/lib/ruby/gems/3.2.0' , execute `gem env` for more information
        from /Users/andre/.rubies/ruby-3.2.0/lib/ruby/site_ruby/3.2.0/rubygems/dependency.rb:326:in `to_spec'
        from /Users/andre/.rubies/ruby-3.2.0/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_gem.rb:57:in `gem'
        from extconf.rb:430:in `process_recipe'
        from extconf.rb:838:in `<main>'

2. I think that's a bug in the --platform switch? Maybe? Bundler does install mini_portile2 as a dependency of nokogiri on x86_64-darwin.

Should be fixed now! (and the --platform option removed, because it breaks caching and honestly is a bad experience)

Cool, thank you!

Oh right, looking back over my previous post, I still have a question: with exec gems installing to a different location that isn't managed by gem install and gem uninstall...

1. how does the user uninstall a gem installed with exec? is that possible?
2. how does the end user handle gem installations that fail? do they just get the same error messages as for gem install?

and I guess also
3. is there any html or other written documentation that needs to be updated for this change?

1. how does the user uninstall a gem installed with exec? is that possible?
   it would be possible by setting GEM_HOME to the gem_exec gem home and then running gem uninstall
2. yeah, should be the same error messages since we're using the same installation code as gem install is
3. I don't think so? the command has a --help output

I didn’t think of this until just now, but does gem exec gem uninstall foo work to remove a gem after installing it via gem exec foo? if so I think that’s a good solution to any possible questions raised by the alternate install directory.

It does not work, since gem isn't provided by any gems

❯ ruby -Ilib -S gem exec --verbose gem
running gem exec with:
           version: >= 0
        executable: gem
          gem_name: gem

HEAD https://index.rubygems.org/
200 OK
GET https://index.rubygems.org/info/gem
200 OK
ERROR:  Could not find a valid gem 'gem' (>= 0) in any repository
GET https://rubygems.org/latest_specs.4.8.gz
304 Not Modified
ERROR:  Possible alternatives: zxygemm, 42_gem, AABeginnerTestGem, AccountGem, Alonso_gem, AndyFirstGem, Backup_GEM_2, BeverageMaker, BidManagerLoggerGem, BoardGameGem

Ok, I think I’m going to request to special case gem exec gem (sorry), because then no one has to manually set GEM_HOME to work with the exec install dir using the commands they already know.

OK, gem exec gem now works!

Okay, this looks good to me! Going to restart the jobs that aren't passing.

🤔 Sadly there's gem called gem already pushed to rubygems.org (https://rubygems.org/gems/gem). That's going to conflict with gem exec gem if I understand it well.

I have good news, better news, and bad news.

The good news: the gem gem doesn't have a gemspec in it, so rubygems will never find a gem command to conflict.

The better news is that the gem was handed over to the RubyGems team (by adding Evan Phoenix as an owner). If needed, we can always yank it, but since it has no executable I don't think it matters.

The bad news is that the gem gem is a prerelease, and that made me realize that gem exec needs to support --pre to run commands from prerelease versions if those versions are newer/higher than the newest non-pre-release. So this isn't quite done. Sorry. 😬

@indirect --pre already was in there & supported! But I added some tests to cover it.

All builds are finally green!!

🎉

Should yank/delete the gem called "gem". That seems like a (minor) security risk to me.

I could see yanking the gem gem or at least blocking it from download or new version updates.

The gem called gem has been handed over to the RubyGems team. If we were to yank it, the name would immediately open up for anyone else to take over, which would create a completely new security risk that does not exist today. We're not going to yank it.

I submitted rubygems/rubygems.org#3569 to address this concern.

very helpful! 🎉