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.

2 Likes
4

It seems like we have some consensus here for (2) question, in most cases we have a single default test config. What about (1) question? I think restrictive approach is better, or in some cases can be a straightforward default type/value.

Also in some cases a test mock implementation for traits can be an alternative for a test env setup. But this does not concern the default configs.

5

If we are proceeding with a single default test config, shouldn’t we take a more open approach instead to reduce the need of unnecessary overrides?

6

Yeah, good point. Then I would say we should seek form some default/common type/value.
What else could a more open approach mean?

1 Like
7

What I suggest we pursue is an approach whereby:

  1. TestDefaultConfig are as present and expressive as possible.
  2. DefaultConfig provide defaults only for types that we know are safe and sane, such as RuntimeEvent = RuntimeEvent and such, and leave all of the rest to be implemented later.

I know there is a small technical issue with this, in that you cannot specify which types are #[no_default] in which prelude. For example MaxLocks can probably be 256 in TestDefaultConfig but must be provided in DefaultConfig. I am optimistic this solve-able at the rust language level with some tricks.

The idea is for DefaultConfig is to be really only the fool-proof defaults.

1 Like