That's indeed the ideal behavior but it's a mess to maintain because the
version of RubyGems shipped with each patchlevel of Ruby changes. We
could try looking at the `VERSION` constant in `
RbConfig::CONFIG["rubylibdir"` but for now I calling what's in there now
as good enough.
40ccf2b093
The $0 value is used in many CLI libraries to determine the name of the
application, when displaying help and error messages.
Without setting this value, it defaults to `gem` which can be confusing.
Before:
```
$ gem exec kamal help
Commands:
gem accessory # Manage accessories (db/redis/search)
gem app # Manage application
gem audit # Show audit log from servers
gem build # Build application image
gem config # Show combined config (including secrets!)
gem deploy # Deploy app to servers
gem details # Show details about all containers
gem docs [SECTION] # Show Kamal configuration documentation
gem help [COMMAND] # Describe available commands or one specific command
gem init # Create config stub in config/deploy.yml and secrets stub in .kamal
gem lock # Manage the deploy lock
gem proxy # Manage kamal-proxy
gem prune # Prune old application images and containers
gem redeploy # Deploy app to servers without bootstrapping servers, starting kamal-proxy, pruning, and registry login
gem registry # Login and -out of the image registry
gem remove # Remove kamal-proxy, app, accessories, and registry session from servers
gem rollback [VERSION] # Rollback app to VERSION
gem secrets # Helpers for extracting secrets
gem server # Bootstrap servers with curl and Docker
gem setup # Setup all accessories, push the env, and deploy app to servers
gem upgrade # Upgrade from Kamal 1.x to 2.0
gem version # Show Kamal version
```
After:
```
$ gem exec kamal help
Commands:
kamal accessory # Manage accessories (db/redis/search)
kamal app # Manage application
kamal audit # Show audit log from servers
kamal build # Build application image
kamal config # Show combined config (including secrets!)
kamal deploy # Deploy app to servers
kamal details # Show details about all containers
kamal docs [SECTION] # Show Kamal configuration documentation
kamal help [COMMAND] # Describe available commands or one specific command
kamal init # Create config stub in config/deploy.yml and secrets stub in .kamal
kamal lock # Manage the deploy lock
kamal proxy # Manage kamal-proxy
kamal prune # Prune old application images and containers
kamal redeploy # Deploy app to servers without bootstrapping servers, starting kamal-proxy, pruning, and registry login
kamal registry # Login and -out of the image registry
kamal remove # Remove kamal-proxy, app, accessories, and registry session from servers
kamal rollback [VERSION] # Rollback app to VERSION
kamal secrets # Helpers for extracting secrets
kamal server # Bootstrap servers with curl and Docker
kamal setup # Setup all accessories, push the env, and deploy app to servers
kamal upgrade # Upgrade from Kamal 1.x to 2.0
kamal version # Show Kamal version
```
4fd060b96d
A default gem does not always live in the same place. For example,
Bundler may be installed to `site_dir` when RubyGems have been upgraded.
A more reliable way seems to actually activate the default gem, so that
we can know for sure where it lives.
c69f6dfb18
The fact that under the hood the upgrade is done through a
rubygems-update gem is an implementation detail that does not really
help users to know.
Plus, it reads a bit weird.
0fa5c50258
It's the `Gem::Installer` below what installs executables, and the code
being deleted here is now actually creating a `gems/` folder in the root
of the source repo when running `ruby setup.rb`.
0e69a8b0d6
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
