SDD 0028 - Reusable Commodore Component Configuration Packages

[simu]

Checklist

• [x] Keep pull requests small so they can be easily reviewed.
• [x] Update the documentation.

[simu]

This looks like a good approach.

As for the question of using remote inventories or implementing a custom solution: If I understand the approach correctly, using Kapitan remote inventories will lead to package fetching working differently than a user would expect (e.g. not being able to overwrite already included packages).

I think I would slightly prefer the custom approach. This will lead to a bit more custom code, but probably leads to a better user experience.

Please see the latest version. I've now defined the package specification and inclusion more explicitly. This changes the trade-off between Kapitan's remote inventory and Commodore-native remote inventory a bit, as we now have to transform the user-provided config into Kapitan's format if we want to use Kapitan's remote inventory. My guess is that this will reduce the difference in implementation complexity between the native and Kapitan fetching from the earlier proposal.

[glrf]

Please see the latest version. I've now defined the package specification and inclusion more explicitly. This changes the trade-off between Kapitan's remote inventory and Commodore-native remote inventory a bit, as we now have to transform the user-provided config into Kapitan's format if we want to use Kapitan's remote inventory. My guess is that this will reduce the difference in implementation complexity between the native and Kapitan fetching from the earlier proposal

Looks good, this is more or less how I expected the custom approach to work. You're right we can probably make it work the same way when using Kapitan's remote inventory. It just feels a bit "hacky"? I would probably still go with the custom approach, but I don't really have strong feelings either way

[simu]

Please see the latest version. I've now defined the package specification and inclusion more explicitly. This changes the trade-off between Kapitan's remote inventory and Commodore-native remote inventory a bit, as we now have to transform the user-provided config into Kapitan's format if we want to use Kapitan's remote inventory. My guess is that this will reduce the difference in implementation complexity between the native and Kapitan fetching from the earlier proposal

Looks good, this is more or less how I expected the custom approach to work. You're right we can probably make it work the same way when using Kapitan's remote inventory. It just feels a bit "hacky"? I would probably still go with the custom approach, but I don't really have strong feelings either way

I'm tending towards the Commodore-native implementation as well, since I think we'll end up with a cleaner implementation, even if there's a bit more of it.