Design Draft: Pligos as a helm manager

In an ideal world, Pligos would be very simple. We would have our input, which is the flavor and our Pligos configuration and this would generate the helm chart to play with

(flavor, pligoscfg) -> chart -> helm install $chart

however we identified that the world is in fact kind of messy and that helm actually generates artifacts on it's own (requirements.lock, charts/*.tgz) which kind of kills this workflow.

To solve this issue I can identify two solutions. The first solution takes away all the power from pligos and makes it a helm plugin that only copies over the manifest templates and values.yaml. The solution is described here: https://github.com/real-digital/pligos/wiki/Design-Draft:-Pligos-as-a-Helm-Plugin

The second solution is to give Pligos all the power and let it deal with all the helm goodies, such as downloading dependencies, templating manifests locally or deploying the chart to the cluster. The upside to this is that we gain all the power. The downside of course is, that we are starting to re-implement all the helm features, which shouldn't be the goal of pligos. However what we could do, and what would be a compromise in order to avoid reimplementing helm features, is simply calling the helm binary with user configured flags.

One example call of pligos could be

pligos dev -- upgrade --install app-dev

which would then run helm upgrade --install app-dev in the background usind the dev context. Pligos would generate the chart in the background and move to the directory hosting the generated chart before calling the command. The two dashes -- seperate the Pligos arguments from the helm arguments, a design which is already used by kubectl.

In order to solve the problem of helm generated artifacts, such as requirements.lock Pligos needs to get a little bit smarter. What Pligos will do is

1. generate the chart and keep it in memory
2. call the user provided command, such as dep up --skip-refresh on the generated chart after writing it to disk
3. load the chart after calling the command into memory. We now have two charts in memory: (a) pre-command call and (b) post-command call
4. compare (a) and (b)
5. write the difference into a directory pligos/.helm-artifacts/context, such that we would end up with a file pligos/.helm-artifacts/dev/requirements.lock

on subsequent runs, pligos picks up those artifacts prior to calling the command and copy it into the generated chart. I would further suggest to make the chartDependencies key context specific as this would now be fully supported by this approach.