github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/book/03-packages/03-editing-a-package.md (about)

     1  kpt does not maintain any state on your local machine outside of the directory where you fetched the
     2  package. Making changes to the package is accomplished by manipulating the local filesystem. At the
     3  lowest-level, _editing_ a package is simply a process that either:
     4  
     5  - Changes the resources within that package. Examples:
     6    - Authoring new a Deployment resource
     7    - Customizing an existing Deployment resource
     8    - Modifying the Kptfile
     9  - Changes the package hierarchy, also called _package composition_. Examples:
    10    - Adding a subpackage.
    11    - Create a new dependent subpackage.
    12  
    13  At the end of the day, editing a package will result in a Git commit that fully specifies
    14  the package. This process can be manual or automated depending on your use case.
    15  
    16  We will cover package composition later in this chapter. For now, let's focus on editing resources
    17  _within_ a package.
    18  
    19  ## Initialize the local repo
    20  
    21  Before you make any changes to package, you should first initialize and commit the pristine package:
    22  
    23  ```shell
    24  $ git init; git add .; git commit -m "Pristine wordpress package"
    25  ```
    26  
    27  ## Manual edits
    28  
    29  As mentioned earlier, you can manually edit or author KRM resources using your favorite editor.
    30  Since every KRM resource has a known schema, you can take advantage of tooling that assists in
    31  authoring and validating resource configuration. For example, [Cloud Code] extensions for VS Code
    32  and IntelliJ provide IDE features such as auto-completion, inline documentation, linting, and snippets.
    33  
    34  For example, if you have VS Code installed, try modifying the resources in the `wordpress` package:
    35  
    36  ```shell
    37  $ code wordpress
    38  ```
    39  
    40  ## Automation
    41  
    42  Oftentimes, you want to automate repetitive or complex operations. Having standardized on KRM for
    43  all resources in a package allows us to easily develop automation in different
    44  toolchains and languages, as well as at levels of abstraction.
    45  
    46  For example, setting a label on all the resources in the `wordpress` package can be done
    47  using the following function:
    48  
    49  ```shell
    50  $ kpt fn eval wordpress -i set-labels:v0.1 -- env=dev
    51  ```
    52  
    53  [Chapter 4] discusses different ways of running functions in detail.
    54  
    55  [cloud code]: https://cloud.google.com/code
    56  [chapter 4]: /book/04-using-functions/