4e9e017cd2
Python resource constructor overloads were recently added that accept a
`<Resource>Args` class for input properties, as an alternative to the
other constructor overload that accepts keyword arguments. The name of
the new args class is the name of the resource concatenated with an
`Args` suffix.
Some providers (e.g. Kubernetes, Azure Native, and Google Native) have
input types with the same name as resources in the same module, which
results in two different `<Resource>Args` classes in the same module.
When you try to use the new args class with the constructor, e.g.:
```python
pulumi_kubernetes.storage.v1.StorageClass(
resource_name='string',
args=pulumi_kubernetes.storage.v1.StorageClassArgs(...),
opts=pulumi.ResourceOptions(...),
)
```
You run into an error, because
`pulumi_kubernetes.storage.v1.StorageClassArgs` is actually referring to
the existing input type rather than the intended `StorageClassArgs`
class for the constructor arguments.
Having the duplicate classes hasn't broken existing usage of the input
type because we "export" all the input types for a module _after_ all
the resources and resource args classes are exported, so the input type
just ends up "overwriting" the duplicate resource args class.
Other languages don't have this problem because the input type is either
in it's own module/namespace (e.g. Node.js and .NET) or a different name
is used for the input type (Go). But with Python, the input types and
resources are all available in the same module.
To address this for Python, when there is an input type in the same
module with the same name as the resource, the args class for the
resource will be emitted as `<Resource>InitArgs` instead of
`<Resource>Args`.
|
||
|---|---|---|
| .. | ||
| templates | ||
| .gitignore | ||
| bundler.go | ||
| examples.go | ||
| gen.go | ||
| gen_function.go | ||
| gen_kubernetes.go | ||
| gen_test.go | ||
| README.md | ||
| utils.go | ||
| utils_test.go | ||
Docs generator
This generator generates resource-level docs by utilizing the Pulumi schema.
Crash course on templates
The templates use Go's built-in html/template package to process templates with data. The driver for this doc generator (e.g. tfbridge for TF-based providers) then persists each file from memory onto the disk as .md files.
Although we are using the html/template package, it has the same exact interface as the text/template package, except for some HTML specific things. Therefore, all of the functions available in the text/template package are also available with the html/template package.
- Data can be injected using
{{.PropertyName}}. - Nested properties can be accessed using the dot notation, i.e.
{{.Property1.Property2}}. - Templates can inject other templates using the
{{template "template_name"}}directive.- For this to work, you will need to first define the named template using
{{define "template_name"}}.
- For this to work, you will need to first define the named template using
- You can pass data to nested templates by simply passing an argument after the template's name.
- To remove whitespace from injected values, use the
-in the template tags.- For example,
{{if .SomeBool}} some text {{- else}} some other text {{- end}}. Note the use of-to eliminate whitespace from the enclosing text. - Read more here.
- For example,
- To render un-encoded content use the custom global function
htmlSafe.- Note: This should only be used if you know for sure you are not injecting any user-generated content, as it by-passes the HTML encoding.
- To print regular strings, that share the same syntax as the Go templating engine, use the built-in global function
printfunction.- For example, if you need to render
{{% md %}}, you will instead need to do{{print "{{% md %}}"}}.
- For example, if you need to render
Learn more from here: https://curtisvermeeren.github.io/2017/09/14/Golang-Templates-Cheatsheet
Modifying templates and updating tests
We run tests that validate our template-rendering output. If you need to make change that produces a set of Markdown files that differs from the set that we use in our tests (see codegen/internal/test/testdata/**/*.md), your pull-request checks will fail, and to get them to pass, you'll need to modify the test data to match the output produced by your change.
For minor diffs, you can just update the test files manually and include those updates with your PR. But for large diffs, you may want to regenerate the full set. To do that, from the root of the repo, run:
PULUMI_ACCEPT=true pushd pkg/codegen/docs && go test . && popd
bundler.go
This file contains a main function and is part of the main package. We run it using the go generate command (see the Makefile and the starting comment in pkg/codegen/gen.go).
This file is ignored using a
+build ignorecomment at the top of the file, so it is not ignored during ago build ....
packaged.go
A file generated by bundler.go that contains formatted byte strings, that represent the string templates from the ./templates/ folder. This file is also git-ignored as it is intended to only be generated by the docs repo and is not used during runtime of the main Pulumi CLI. In fact, this whole package is not used during the runtime of the CLI itself.
go:generate
Read more here.
go:generate is a special code comment that can be used to run custom commands by simply running go generate <package>, which then scans for go:generate comments in all sources in the package <package>. It also serves as a way to document, that a certain file relies on a command to have been executed before it can be used.