RSDK-9726 - improve modulegen help text and deprecate resource-type flag

[stuqdog]

Provides improved help text in terms of the usage invocation, as well as clarifying the role/usage of the language, model-name, name, public-namespace, and resource-subtype flags.

Additionally, removes resource-type as a flag we pay attention to/care about. While still supported for backwards compatibility, it is invisible and ignored. This flag is a gotcha since each subtype only has one valid type (except generic, but we can carve out a specific case for that), and a user shouldn't reasonably be expected to understand the component/service distinction that is primarily internal.

Tested by creating modules using both old and new code and diffing them to ensure no changes in behavior.

Old help text:

NAME:
   viam module generate - generate a new modular resource via prompts

USAGE:
   viam module generate [command options] [arguments...]

OPTIONS:
   --enable-cloud            generate Github workflows to build module (default: false)
   --language value          language to use for module
   --model-name value        resource model name to use in module
   --name value              name to use for module
   --public                  set module to public (default: false)
   --public-namespace value  namespace or organization ID of module
   --register                register module with Viam to associate with your organization (default: false)
   --resource-subtype value  resource subtype to use in module
   --resource-type value     resource type to use

New help text:

NAME:
   viam module generate - generate a new modular resource via prompts

USAGE:
   viam module generate --name=<name> --language=<language> --resource-subtype=<resource-subtype> --model-name=<model-name> --public-namespace=<public-namespace> [other options]

OPTIONS:
   --enable-cloud            generate Github workflows to build module (default: false)
   --language value          language to use for module, can be one of [python, go]
   --model-name value        name for the particular resource subtype implementation. for example, a sensor model that detects moisture might be named 'moisture'
   --name value              name to use for module. for example, a module that contains sensor implementations might be named 'sensors'
   --public                  set module to public (default: false)
   --public-namespace value  namespace or organization ID of module. must be either a valid organization ID, or a namespace that exists within a user organization
   --register                register module with Viam to associate with your organization (default: false)
   --resource-subtype value  resource subtype to use in module, for example arm, camera, or motion. see https://docs.viam.com/dev/reference/glossary/#term-subtype for more details

[stuqdog]

a bit of flyby logic here. previously, the CLI would complain if we passed power-sensor but not power_sensor. Changes here enable us to be more case-agnostic for multi-word resource subtypes.

[stuqdog]

cc @ale7714

[stuqdog]

Probably gonna hold off on merging this until #4692 is in, as that feature changes some formatting stuff and I want to ensure consistency. cc @purplenicole730

[ale7714]

looks great! and thank you for thinking about resource type/subtype a little bit more in depth, it's good to be aware of this

[purplenicole730]

Could you also update the module generation workflow?

[stuqdog]

Could you also update the module generation workflow?

Sure! Maybe dumb question, but what do you want to see updated? it seems to me that we want to keep the workflow basically the same except stop asking for unnecessary information, which I think this PR achieves?

[purplenicole730]

Could you also update the module generation workflow?

Sure! Maybe dumb question, but what do you want to see updated? it seems to me that we want to keep the workflow basically the same except stop asking for unnecessary information, which I think this PR achieves?

I'm pretty sure the workflow still uses the flag you're trying to stop using, so I think it'd be good to also follow that there!

[stuqdog]

I'm pretty sure the workflow still uses the flag you're trying to stop using, so I think it'd be good to also follow that there!

@purplenicole730 I think we should be good on that! It isn't visible as a flag (though it's still supported of course for backwards compatibility), and the promptUser version already had subtype and type combined into a single field.

Screenshots:

[stuqdog]

Oh though actually there was an issue where we were listing Generic Component Component and Generic Service Service instead of just Generic {type} in the user prompt, which is now fixed :)

[stuqdog]

Possibly I'm misunderstanding but just to clarify: at no point are we using the flag at this point. You can confirm this by the removal of ResourceType as field of the moduleGenArgs type. We do still care about resource type of course and it is still a field on ModuleInputs, but (like the Resource field of ModuleInputs), it is inferred based on what was actually asked for rather than being directly asked for (since while we care about what it is, we don't care about a user knowing what it is).

[stuqdog]

Just spoke offline, @purplenicole730 clarified that it was the CI workflow that needed updating :) which is now done!

[purplenicole730]

woo!