Frank Farzan

Couple of comments/suggestions: 1. Options provided in https://github.com/GoogleContainerTools/kpt/issues/2567#issue-1043001437 aren't mutually exclusive. A function container could be run locally (e.g. docker, podman, gvisor?, etc.), could be run on a container scheduler...

Common utilities should be provided by the SDK, instead of have a library maintain in the catalog repo.

Moved to m4

This includes testing all packages in `package-examples` directory. Currently we have multiple methods for testing: 1. Tests embedded in documentation. 2. Hydration-only: test harness using `.expected` directory 3. Live e2e...

This is a cross-cutting and critical part of having good UX when manipulating KRM resources. Even most basic functions like name-prefix require augmented OpenAPI semantics to work properly. Kustomize has...

There are multiples aspects to consider here: 1. UX - What's the desired e2e user journey here? This deserves a brief user guide before we can about function impl. -...

This can potentially be provided as an option, but not done unconditionally. It should be possible to invoke post-processor function(s) imperatively after rendering a package: ``` $ kpt pkg get...

One of the use cases for `eval` is to execute a function from a CI/CD system on packages authored by other teams: https://kpt.dev/book/04-using-functions/02-imperative-function-execution So for example, a package pipeline can...

> What if you later update the package? Don't you need to re-render then anyways? > > IMO we should really be pushing for idempotent render. In the CI/CD use...

We should also get rid of tests that use `docker` directly. We should only use `kpt` CLI.