Design Draft: distributed flavor management

Pligos was built as a tool to make my life easier. That also means that it fits very well to my requirements, which, for the most part, don't require me to host flavors in a shared space. However, I think it's crucial that we make this possible. Right now there are a few issues that need to be overcome in order to make that happen:

• Sharing access to Flavors, just as with 'normal' helm charts means we need versioning.
• If we have versioning, we probably also want to introduce some method to lock versions
• there is not only Flavors but also types. Do we need to version those as well, probably?
• right now Flavors are somewhat loosely coupled to types. However, we need to make sure that users of a Flavor also get the correct types.

types and Flavors

I think we need to overthink the relationship between the two. Right now the connection is made through the Pligos configuration, which actually is kind of bad. Up until now, this wasn't recognized, because there only ever was one version of the two. However, types and Flavors are tightly coupled and if we start versioning types we need to be able to define a type version from within the Flavor.

This means we have two options right now: host the types together with the Flavor and give up the shared API between Flavors, or, invent a type repository.

hosting Flavors

This part might actually be easy? We could just introduce a flavors.yaml that mimics the requirements.yaml and use the already existing helm code to manage a flavors.lock file. Flavors would than simply be hosted as part of a traditional chart repository.