Skip to content

Grab Bag of CLI refactorings #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Dec 28, 2024
Merged

Conversation

QMalcolm
Copy link
Collaborator

Is there an associated github issue?

No

What is this PR changing?

The provided CLI was a bit disorganized / inconsistent in its patterns. This PR is just to do a bit of cleanup

  • change system to systems
  • merge list-systems into systems command
  • move character generation to characters command
  • create shared CLI arg definitions
  • add system_parser custom arg parser to reduce code duplication
  • improve on function signature pattern matching
  • some better error messages

The `system` dealt with as many systems as were available (i.e.
multiple). As such, it makes sense for it to be plural, hence `systems`.
Previously anytime a system arg was passed to a command, we rewrote the
system loading logic. Now anytime the system arg is used, as part of
that process the rule system will automatically get loaded.
Previously it was under `systems gen stat-block`. However the nesting
under `systems was unnecessary. For now we're gonna put generation
commands that don't have a distinct generation association under the
base `gen` command.
With the removal of `gen` CLI subcommand of `systems` in the previous
commit, the only sub command being handled by the "general"
`handle_systems_subcommands` method was `:show`. As such, it made sense
to flatten the child function being called into a patterned matched on
`:show` version of `handle_systems_subcommands`.

Of note, this seems to be a generally useful pattern, that is having
handling functions pattern match on the command. If we expanded this
paradigm to subcommands, we'd approach a system which each
command + sub-command combo chain has it's own individual handler. If
that becomes the rule, it might make sense to extend `optimus` such that
leaf commands simply define their handler in the spec. This would
elimate the need for functions which mostly seem to becoming routing.
@QMalcolm QMalcolm merged commit dd1a634 into main Dec 28, 2024
1 check passed
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.

1 participant