Skip to content
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

CLI tool codgen command: How to apply recursive derives and attributes? #1353

Closed
tadeohepperle opened this issue Jan 10, 2024 · 1 comment · Fixed by #1379
Closed

CLI tool codgen command: How to apply recursive derives and attributes? #1353

tadeohepperle opened this issue Jan 10, 2024 · 1 comment · Fixed by #1379
Labels
needs thought We need to resolve some questions before we can work on this

Comments

@tadeohepperle
Copy link
Contributor

Alex raised this question here and after the PR is merged, we need to decide how to implement recursive derives and attributes in the CLI tool.

Right now, you specify derives and attributes like this:

subxt codegen --derive-for-type my_module::my_type=serde::Serialize --attributes-for-type my_module::my_type=#[allow(clippy::all)]

There are these options in my opinion (in order of my preference):

  • A: Add new arguments --derive-for-type-recursive and --attributes-for-type-recursive.
  • B: Make all derives recursive by default: This would make sense in most cases, but maybe not in all.
  • C: Introduce a new input format per derive, e.g. subxt codegen --derive-for-type my_module::my_type=serde::Serialize/recursive so we just adjust the derive_for_type_parser function to check for this flag. This requires some weird syntax though, that the user has to know about.
  • D: Have no recursive derives in the CLI. People need to specify the derives manually (status quo)

I think A would be best, what do you guys think? @niklasad1 @lexnv @jsdw

@tadeohepperle tadeohepperle added the needs thought We need to resolve some questions before we can work on this label Jan 11, 2024
@jsdw
Copy link
Collaborator

jsdw commented Jan 18, 2024

I'd be up for A or C myself (A is fine for now, but runs into a future limitation if we ever add more options to derives other than "recursive", and C would be more tricky because if we went that route I'd want a general approach to passing arbitrary options to derives that also wasn't syntactically hideous, possible eg being able to have comma separated options after eg my_module::my_type=serde::Serialize,recursive,foo=123)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs thought We need to resolve some questions before we can work on this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants