Skip to content

Support root commands that doesn't implement call#135

Merged
katafrakt merged 8 commits intodry-rb:mainfrom
gustavothecoder:namespace-concept
Feb 10, 2026
Merged

Support root commands that doesn't implement call#135
katafrakt merged 8 commits intodry-rb:mainfrom
gustavothecoder:namespace-concept

Conversation

@gustavothecoder
Copy link
Copy Markdown
Contributor

@gustavothecoder gustavothecoder commented Jul 24, 2024

Resolve #96

I would like to add descriptions to my root commands without implementing a proper command, like a namespace.

Example

Command

class Namespace < Dry::CLI::Namespace
  desc "This is a namespace"

  class MyCommand < Dry::CLI::Command
    desc "I'm a concrete command"

    def call(**params)
      puts "I'm a concrete command"
    end
  end
end

Result

image

end
end

class Namespace < Dry::CLI::Command
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't bizarre to have a "command" that the uniq usage is to print top level usage? I am wondering if it should be a better idea to move the usage of top class as specific dsl. Like suggested here #96 ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is. I tried to implement the suggestion from #96, but I couldn't figure out how to do it. Maybe we can create the Dry::CLI::Namespace class, so It will look less strange.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gustavothecoder I like the idea of this being a specialised Namespace class. That way, when the class is used, it will be clearer that its purpose is to provide information about a grouping of subcommands only, and not its own distinct command behaviour.

I prefer this help text residing in a concrete class instead of being part of the top-level command registration API, since that feels more consistent with how the rest of the CLI construction is done: a class for each thing.

If you're still interested in working on this PR, I'd love it if you could make this adjustment! Let me know what you think.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timriley Done! I think it looks better using the Namespace class.

@benoittgt
Copy link
Copy Markdown
Contributor

This is a great proposal. I would love to be able to use this in our CLI.

@timriley
Copy link
Copy Markdown
Member

timriley commented Jan 1, 2026

Hi @gustavothecoder!! Happy new year :) Firstly, I want to apologise for the delay in attending to all your excellent PRs. Good news, though — in January we'll be focusing on getting a new dry-cli shipped with all your work incorporated. We'll be back in touch in the PRs. Thank you for your contributions!

@katafrakt katafrakt merged commit 1e8cb6a into dry-rb:main Feb 10, 2026
8 checks passed
@benoittgt
Copy link
Copy Markdown
Contributor

Thanks a lot @katafrakt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow adding subcommand toplevel documentation (usage)

4 participants