Seeking Feedback on `derive_impl` for Default Configurations in Pallet Templates

Ecosystem
1

Hello everyone! :wave:

We’ve been working on derive_impl that aims to simplify the inclusion of pallets in a runtime by providing default configurations. Here is an example that demonstrates the significant reduction in required config parameters for frame_system when used in tandem with derive_impl. This has been particularly useful for the addition of new features such as Tasks without requiring a change at the impl site.

Over the past few months as we tried to expand the usage to other pallets, we’ve encountered a few important questions and would love to hear your thoughts.

Concerns Raised:

  1. Restrictiveness vs. Flexibility:
  • Should these default configurations be as restrictive as possible, minimizing unexpected issues? Or should they be more open?
  • Striking the right balance is crucial. Too restrictive, and everyone ends up practically overriding the defaults. Too open, and we risk potential unexpected configurations in the runtime.
  1. Number of Default Configurations:
  • How many default configurations should we provide? We see significant benefits for tests, but these configurations could also be useful for production runtimes, especially to prevent breaking changes if a No-Op is set as the default.
  • Finding the sweet spot between simplicity and comprehensiveness is essential.

Your Input Matters:

Please share your thoughts on the following:

  • What level of restrictiveness do you prefer for default configurations?
  • How many default configurations would be ideal?
  • Any other considerations or experiences related to derive_impl?

Looking forward to hearing from you all! Feel free to comment below or share your views. Let’s make derive_impl even better! :blush:

2 Likes
2

I would like to keep it for test/mock only. If there is a new item, while it could be safe to use a default value, I would still like to know a new item is introduced and double check myself that a default value is safe or if we want to configure it to something else to leverage this new feature.

In the end, we have ~30 mocks and only 2 production runtime in Acala repo. I don’t mind adding the new config twice but I don’t want to do it 30 times.

3 Likes
3

I think production runtimes should not use derive_impl. For testing it is a no-brainer positive thing to have. The only real runtime times that I wish to have derive_impl is templates. It would be a nice-to-have for a template that is meant to onboard a new developer to be leaner.

1 Like