docs: updated meta resources related behavior in kpt fn docs (#3187)

Author: droot

internal/docs/generated/fndocs/docs.go

@@ -43,11 +43,6 @@ This _package hierarchy_ contains two packages:
    `Kptfile`. This package contains 3 resources in
    `wordpress/mysql/deployment.yaml` file.
 
-The `Kptfile` is an example of a _meta resource_ in kpt. Meta resources are
-resources that are only consumed by the kpt tool. They do not have extrinsic
-meaning and are not applied to a cluster. We will see other types of a meta
-resources in the next section.
-
 kpt uses Git as the underlying version control system. A typical workflow starts
 by fetching an _upstream_ package from a Git repository to the local filesystem
 using `kpt pkg` commands. All other functionality (i.e. `kpt fn` and `kpt live`)

internal/docs/generated/pkgdocs/docs.go

@@ -11,7 +11,7 @@ For example, when consuming an upstream package, the initial workflow can look l
 - **Get**: Using `kpt pkg get`
 - **Explore**: Using an editor or running commands such as `kpt pkg tree`
 - **Edit**: Customize the package either manually or automatically using `kpt fn eval`. This may
-  involve editing meta resources such as the functions pipeline in the `Kptfile` which is executed
+  involve editing the functions pipeline in the `Kptfile` which is executed
   in the next stage.
 - **Render**: Using `kpt fn render`
 

site/book/02-concepts/01-packages.md

@@ -70,8 +70,7 @@ fundamentally different approaches:
   the `functionConfig` is specified as CLI argument. This is an imperative way
   to run functions. Since the function is provided explicitly by the user, an
   imperative invocation can be more privileged and low-level than an declarative
-  invocation. For example, it can optionally operate on meta resources or have
-  access to the host system.
+  invocation. For example, it can have access to the host system.
 
 We will discuss how to run functions in Chapter 4 and how to develop functions
 in Chapter 5.

site/book/02-concepts/02-workflows.md

@@ -5,7 +5,7 @@ lowest-level, _editing_ a package is simply a process that either:
 - Changes the resources within that package. Examples:
   - Authoring new a Deployment resource
   - Customizing an existing Deployment resource
-  - Modifying the Kptfile or other meta resources
+  - Modifying the Kptfile
 - Changes the package hierarchy, also called _package composition_. Examples:
   - Adding a subpackage.
   - Create a new dependent subpackage.
@@ -40,8 +40,8 @@ $ code wordpress
 ## Automation
 
 Oftentimes, you want to automate repetitive or complex operations. Having standardized on KRM for
-all resources in a package (including meta resources) allows us to easily develop automation in
-different toolchains and languages, as well as at levels of abstraction.
+all resources in a package allows us to easily develop automation in different
+toolchains and languages, as well as at levels of abstraction.
 
 For example, setting a label on all the resources in the `wordpress` package can be done
 using the following function:

site/book/02-concepts/03-functions.md

@@ -41,7 +41,6 @@ When you have one of these use cases:
 - Perform a one-time operation
 - Execute a function from a CI/CD system on packages authored by other teams
 - Develop shell scripts and chain functions with the Unix pipe (`|`)
-- Mutate meta resources such as the `Kptfile` (Not allowed by `render`)
 - Execute the function with privilege (Not allowed by `render`)
 
 We will cover these topics in detail.
@@ -134,8 +133,7 @@ Here is the list of available exclusion flags:
 
 Since the function is provided explicitly by the user, `eval` can be more
 privileged and low-level than a declarative invocation using `render`. For
-example, it can optionally operate on meta resources or have access to the host
-system.
+example, it can have access to the host system.
 
 In general, we recommend against having functions that require privileged access
 to the host since they can only be executed imperatively and pose a challenge in
@@ -179,26 +177,6 @@ in read-write mode.
 --mount type=bind,src="/path/to/schema-dir",dst=/schema-dir,rw=true
 ```
 
-### Mutate Meta Resources
-
-By default, functions cannot mutate meta resources i.e. `Kptfile` and
-functionConfig(s). There are use cases for having _meta functions_ that can
-operate on meta resources. For example, they can perform the following:
-
-- Enforce a policy on functions declared in all `Kptfile`(s) in the package
-  hierarchy
-- Add a function to the `validators` list in the `Kptfile`
-- Set the `info.license` field in the `Kptfile` to `Apache-2.0`
-
-This is enabled using the `--include-meta-resources` flag.
-
-For instance, the following will set the labels on all resources in the
-`wordpress` package, including the `Kptfile`:
-
-```shell
-$ kpt fn eval wordpress -i set-labels:v0.1 --include-meta-resources -- app=wordpress env=prod
-```
-
 ## Chaining functions using the Unix pipe
 
 As an alternative to declaring a pipeline in the `Kptfile`, you can chain

site/book/03-packages/03-editing-a-package.md

@@ -103,8 +103,8 @@ fn-args:
   If using never, kpt will only use images from the local cache.
 
 --include-meta-resources, m:
-  If enabled, meta resources (i.e. `Kptfile` and `functionConfig`) are included
-  in the input to the function. By default it is disabled.
+  (DEPRECATED) include-meta-resources is no longer necessary because meta
+  resources are included by default with kpt version v1.0.0-beta.15+.
 
 --mount:
   List of storage options to enable reading from the local filesytem. By default,

site/book/04-using-functions/02-imperative-function-execution.md

@@ -21,9 +21,6 @@ from A is then written to the local filesystem in-place.
 
 `render` formats the resources before writing them to the local filesystem.
 
-Meta resources (i.e. `Kptfile` and `functionConfig`) are excluded from the
-inputs to the functions.
-
 If any of the functions in the pipeline fails, then the entire pipeline is
 aborted and the local filesystem is left intact.
 

site/reference/cli/fn/eval/README.md

@@ -39,8 +39,8 @@ DIR:
   Path to the file containing `functionConfig`.
 
 --include-meta-resources:
-  If enabled, meta resources (i.e. `Kptfile` and `functionConfig`) are included
-  in the output of the command. By default it is disabled.
+  (DEPRECATED) include-meta-resources is no longer necessary because meta
+  resources are included by default with kpt version v1.0.0-beta.15+.
 
 --output, o:
   If specified, the output resources are written to stdout in provided format.