# Seeking Feedback on \`derive\_impl\` for Default Configurations in Pallet Templates **URL:** \ **Category:** Ecosystem\ **Created:** [April 26, 2024, 5:12am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584 "2024-04-26T05:12:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![gupnik](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/gupnik/32/1494_2.png) [@gupnik](https://forum.polkadot.network/u/gupnik)\ **Post date:** [April 26, 2024, 5:12am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/1 "2024-04-26T05:12:59Z")
Hello everyone! 👋 We’ve been working on [`derive_impl`](https://github.com/paritytech/polkadot-sdk/issues/171) that aims to simplify the inclusion of pallets in a runtime by providing default configurations. [Here](https://github.com/paritytech/polkadot-sdk/blob/dd5b06e622c6c5c301a1554286ec1f4995c7daca/substrate/frame/examples/default-config/src/lib.rs#L151) 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! 😊 ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [April 26, 2024, 5:24am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/2 "2024-04-26T05:24:50Z")
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. ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 1, 2024, 4:02pm UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/3 "2024-05-01T16:02:35Z")
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. ---
**Author:** ![Muharem](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@Muharem](https://forum.polkadot.network/u/Muharem)\ **Post date:** [June 6, 2024, 2:35pm UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/4 "2024-06-06T14:35:07Z")
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. ---
**Author:** ![gupnik](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/gupnik/32/1494_2.png) [@gupnik](https://forum.polkadot.network/u/gupnik)\ **Post date:** [June 7, 2024, 9:28am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/5 "2024-06-07T09:28:05Z")
> [@Muharem](#): > > I think restrictive approach is better, or in some cases can be a straightforward default type/value. 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? ---
**Author:** ![Muharem](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@Muharem](https://forum.polkadot.network/u/Muharem)\ **Post date:** [June 7, 2024, 10:56am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/6 "2024-06-07T10:56:09Z")
Yeah, good point. Then I would say we should seek form some default/common type/value. What else could a more open approach mean? ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [June 13, 2024, 1:48am UTC](https://forum.polkadot.network/t/seeking-feedback-on-derive-impl-for-default-configurations-in-pallet-templates/7584/7 "2024-06-13T01:48:13Z")
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.