Why does a Helm chart fail to render with `function "env" not defined` when sprig documents an env function?

### What Helm actually registers Helm renders charts with Go's `text/template`, and it hands that engine a function map built from the sprig library — sprig v3.3.0 in current Helm. That is where the vast majority of the functions a chart calls come from: `default`, `quote`, `trunc`, `upper`, `b64enc`, `coalesce`, the dictionary and list helpers, the date helpers. Helm then adds a small set of its own on top, and — the part that surprises people — *deletes* two of sprig's: `env` and `expandenv`. Because Go's template engine resolves function names when it parses the template, not when it executes it, calling a name that is not in the map is not a runtime nil or an empty string. It is a parse failure, reported as `function "env" not defined`. There is no way to guard it with an `if`: the template does not compile at all. The same error appears from `helm template`, from `helm lint`, and from `helm install`, which at least means the failure is cheap to discover. ### Why they were taken out The argument is that a chart's render must be a pure function of two inputs: the chart, and the values it was given. Hold both constant and the manifest is identical no matter who ran the command. That property is what makes several everyday things work: - `helm template` in CI produces the same YAML that `helm install` will apply, so reviewing the rendered output means something. - Two engineers debugging the same release can reproduce each other's render. - A diff between two renders is signal, not noise about whose shell had which variable exported. An `env` function destroys that. The same chart and the same values would render differently on a developer laptop, on a CI runner and on a build agent, and the difference would be invisible in the chart, in the values files and in the release's stored values. It is also a straightforward exfiltration path: a chart pulled from a public repository could read a registry credential or a cloud token out of the environment of whoever installed it and place it into a rendered object — an annotation, a ConfigMap, anything the chart author chose. ### What to do instead Pass the value in. A pipeline that knows the image digest, the environment name or the config revision sets it explicitly: ```bash helm upgrade --install fanout ./chart \ --set migration.image="$MIGRATION_IMAGE" \ --set-string build.revision="$CI_COMMIT_SHA" ``` This is more than a workaround. It makes the input part of the release: the values Helm stores with the revision record it, and `helm get values` will show what the render actually used. An `env` lookup would leave no trace at all — the release would be unexplainable six months later. Where the data is genuinely a file rather than a scalar, `--set-file` reads a file's contents into a value, which covers the common case of injecting a certificate or a rendered config produced earlier in the pipeline. ### The determinism hole that remains Removing `env` closes one hole; it does not make every chart's render deterministic. The sprig random helpers — `randAlphaNum`, `uuidv4` and their relatives — are present and are re-evaluated on every render. A template that generates a password with `randAlphaNum 24` produces a *different* password on every upgrade, which is why charts that do this pair it with a lookup of the existing object or with the resource-keep annotation. When someone asks why `env` is missing, the follow-up worth volunteering is that determinism is a property the chart author still has to maintain by hand. ### Version note The removal of `env` and `expandenv` is long-standing and identical in Helm 3 and Helm 4 — there is no flag that restores them. Helm 4 did extend the function set in one visible way: it added a duration family (`durationSeconds` through `durationWeeks`, plus `durationRoundTo` and `durationTruncateTo`) that Helm 3.21 does not have. That matters for charts you publish rather than only install yourself: a template using those functions parses under Helm 4 and fails with the same class of `function ... not defined` error on a Helm 3 client, which is a compatibility decision to make consciously rather than discover in someone else's cluster.