This issue proposes making the intermediate registry directory, currently required inside the templates folder pointed to by the --templates parameter, optional or removable.

Currently, we have:

my_templates/   # Directory provided to --templates parameter
  registry/     # Intermediate directory we propose making optional or removable
    go/
    rust/
    ...

Initially, the registry directory matched the first-level Weaver command. For example:

weaver registry generate rust --templates my_templates

This command searches for templates in my_templates/registry/rust. While logical, after several months, this intermediate directory has proven confusing and unnecessary for users.

Instead, users should have flexibility over their template structure. Thus, rather than:

weaver registry generate rust --templates my_templates

Users could simply write:

weaver registry generate rust --templates my_templates/registry

Or, even simpler, eliminate this intermediate level entirely:

weaver registry generate rust --templates my_templates

Another simpler option would be eliminating the target (rust) entirely from the command, allowing the --templates parameter to directly specify the template directory for Rust code generation. However, this simpler option conflicts slightly with another usability enhancement we have in mind: bundling the most common templates directly within Weaver’s binary distribution. Ideally, we would like users to be able to type:

weaver registry generate rust

without specifying --templates, allowing Weaver to use built-in templates by default. Of course, specifying custom targets and template directories would remain possible for advanced users.

In my opinion, the decision boils down to one of the following options:

• Do nothing (keep current structure)
• Make the intermediate directory optional
• Completely remove the intermediate directory and handle migration for users (breaking change)

There might be other approaches worth considering that aren’t listed here. Feel free to suggest additional alternatives in the comments.