Skip to content

subdispatch commands are promoted to top level commands #35

@djerius

Description

@djerius

I'm playing (and not succeeding terribly well) at getting subcommands to work. My expectation is that subcommands live in a namespace which is private to their parent commands. However, that doesn't appear to be so. Here's some test code:

#!/usr/bin/env perl

MyApp->run;

package MyApp;
use App::Cmd::Setup -app;

package MyApp::Command::first;
use base 'App::Cmd::Subdispatch';

sub execute { print __PACKAGE__, "\n" }

package MyApp::Command::first::init;
use base 'App::Cmd::Command';

sub execute { print __PACKAGE__, "\n" }

package MyApp::Command::second;
use base 'App::Cmd::Subdispatch';

sub execute { print __PACKAGE__, "\n" }

package MyApp::Command::second::init;
use base 'App::Cmd::Command';

sub execute { print __PACKAGE__, "\n" };

Executing that code leads to the following error message:

two plugins for command init: MyApp::Command::second::init and MyApp::Command::first::init

If I remove the definition of second::init, I get the following

Available commands:

  commands: list the application's commands
      help: display a command's help screen

     first: (unknown)
      init: (unknown)
    second: (unknown)

And I can execute first::init as if it were a top-level command:

$ ./tpan init
MyApp::Command::first::init

Which isn't what I'd expect. Am I going about this the wrong way?

Thanks.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions