help with-in multiple levels of subcommands having same default_command does not work

[ashrithr]

Having multiple levels of nested subcommands with default_command for some of them causes this problem:
error: undefined method +' for nil:NilClass`
Stack Trace:

/Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help_modules/command_help_format.rb:106:in `block in format_subcommands': undefined method `+' for nil:NilClass (NoMethodError)
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help_modules/command_help_format.rb:104:in `map'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help_modules/command_help_format.rb:104:in `format_subcommands'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help_modules/command_help_format.rb:20:in `format'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help.rb:81:in `show_help'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/commands/help.rb:60:in `block in initialize'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/command_support.rb:136:in `call'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/command_support.rb:136:in `execute'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/app_support.rb:262:in `block in call_command'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/app_support.rb:275:in `call'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/app_support.rb:275:in `call_command'
    from /Users/ashrith/.rvm/gems/ruby-1.9.3-p327/gems/gli-2.5.4/lib/gli/app_support.rb:69:in `run'
    from bin/awscli:314:in `<main>'

Sample Code:

desc 'Testing Interface'
command :test do |test|
  test.desc 'list'
  test.command :list do |list|
    list.action do |global_options,options,args|
      # ...
    end
  end

  test.desc 'create'
  test.command :create do |create|
    create.action do |global_options,options,args|
      # ...
    end
  end

  test.desc 'destroy'
  test.command :destroy do |destroy|
    destroy.action do |global_options,options,args|
      # ...
    end
  end

  #Nested Commands
  test.desc 'key pairs'
  test.command :keys do |kp|

    kp.desc 'create keys'
    kp.long_desc 'creates keys'
    kp.command :create_key_pair do |ckp|
      ckp.action do |global_options,options,args|
        # ...
      end
    end

    kp.desc 'list keys'
    kp.long_desc 'lists available keys'
    kp.command :list_keys do |lkp|
      lkp.action do |global_options,options,args|
        # ...
      end
    end

    kp.desc 'delete keys'
    kp.long_desc 'deletes existing keys'
    kp.command :delete_key do |dkp|
      dkp.desc 'name of the key to delete'
      dkp.arg_name 'name'
      dkp.flag :id
      dkp.action do |global_options,options,args|
        # ...
      end
    end
    kp.default_command :list_keys
  end

  test.default_command :list
end

[ashrithr]

Perfect this fixed the issue.

[ashrithr]

There might be also another small issue with the helo command. For the above same sample code it does not show the command description fot levels greater than 2 depth. As shown in the below example, the commands do not get a description!

bundle exec bin/cliss help test keys
NAME
    keys - key pairs

SYNOPSIS
    cliss [global options] test keys [command options]  [list_keys]
    cliss [global options] test keys [command options]  create_key_pair
    cliss [global options] test keys [command options]  delete_key

COMMANDS
    create_key_pair -
    delete_key      -
    list_keys       - (default)

[davetron5000]

Sorry this took a while, yeah, this seems like a bug.

[davetron5000]

This is mostly a note to myself, but the issue is totally related to #96. GLI aggressively coalesces all flags/switches of subcommands to be "owned" by the parent command. So that said options have documentation, the calls to desc and long_desc do the same thing, and so these get lost. UGH.

[davetron5000]

OK, this should be fixed in 2.5.6. Please let me know if not and thanks again for the test code

[ashrithr]

sure!