**Explore:** Package authors should be able to customize how InstalledPackage values get included in templating steps

[ewrenn8]

In the current alpha, values from the InstalledPackage are appended to the values of the first templating step, which is quite limiting.

To improve this experience for authors, I propose adding a valuesConfig key to the Package definition. Under this key, authors are able to specify which templating step the values will be included in, and can optionally choose to include the namespace as a value as well. It could look something like this: https://gist.github.com/ewrenn8/5d029c1c0c44b12e957119a10733d45f

Some outstanding thoughts:

• What other values may be useful other than namespace, and what is the best way to include them? One example that was brought up was providing the InstalledPackage name as a data value to the templates. If there is a growing list, making them optional keys could get unwieldy.
• Is there a better way to specify which templating step to include the values in?

Making this issue as a discussion ground for potential solutions to this problem, so if there are completely unrelated solutions please post them!

[ewrenn8]

Related: #129

[vibhas]

Adding "Explore" to this issue to work on a proposal. Moving this up in the backlog to give us time to get the proposal reviewed.

[danielhelfand]

Updating this issue with some recent conversation around supporting this:

We are looking to collect more use cases around this feature before moving forward with any proposal. All ideas around how to make use of this feature are welcome to help better inform the final proposal.

[vibhas]

We decided to move this issue to Post-MVP.

[voor]

Bumping this discussion and hoping to rekindle it, as this use case is now very well established when you're using Helm in conjunction with ytt overlays.

You can "hack" this in today leveraging the fact that when you need the value in multiple template steps if you know which one is first you can force things into the second one:

apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
  name: kiam
  annotations:
    kapp.k14s.io/change-rule.1: "delete before deleting gitops.tanzu.vmware.com/cert-manager"
    kapp.k14s.io/change-rule.2: "upsert after upserting gitops.tanzu.vmware.com/cert-manager"
    kapp.k14s.io/change-group: "gitops.tanzu.vmware.com/kiam"
    #! This is a helm based package, and as such needs values passed to both helm and ytt.
    ext.packaging.carvel.dev/ytt-paths-from-secret-name.0: kiam-values
spec:
  packageRef:
    refName: kiam.tanzulabs.tanzu.vmware.com
    versionSelection:
      constraints: ">=0.0.0"
  values:
  - secretRef:
      name: kiam-values

This is amazingly brittle, since you're forced to use paths and not data-values, and as a consumer of a package you really shouldn't have to know the implementation detail of "helm first, then ytt" -- to you it should just be "a package I pass things into"

[st3v]

Another bump. We running into this limitation when building the Crossplane package for TAP. That package depends on a helm chart that must be templated as a first step. At the same time, the package requires its own set of values defined in a dedicated values-schema.yml which would have to be included in a ytt templating step following the initial helmTemplate.

[jessehu]

We have a use case for using helm as the 1st templating step and ytt as the 2nd templating step, both use the same secrets. So it does not require the more flexible solution proposed in this ticket.