Is there a best practice on naming configs? In a r...
# general
r
Is there a best practice on naming configs? In a regular pulumi program should I always just use top-level config entries or is it better to scope all config under one key like
myproject:baseurl
? My question is about simple programs, not higher-level constructs or providers. Is it even better to use top-level configs to avoid overlapping with third party libs / providers?
w
In general we recommend putting all project config in the default namespace (available with just
pulumi config set baseurl value
or with
pulumi config set myproject:baseurl value
). Namespaces are primarily designed for reusable libraries (like
aws
or
cloud
). Once we support structured config (maps and lists), then you will be able to have more hierarchichcal configuration without the need for separating top level config namespaces.
r
I don’t get the difference between default namespace with a colon-based key to using a namespace like
aws
. From CLI perspective both look the same (replace
myproject
by
aws
).
I’m not looking for hierarchical configs but just some naming consistency (e.g. for sorting config keys).
w
Not sure I'm following the latest points. Leaving off the namespace defaults to using the project name as the namespace. The CLI normalizes this down to the simpler form when listing config:
Copy code
luke:~/dd/pulumidemos/myproject
$ pulumi config
KEY         VALUE
aws:region  us-east-1

luke:~/dd/pulumidemos/myproject
$ pulumi config set baseurl value

luke:~/dd/pulumidemos/myproject
$ pulumi config
KEY         VALUE
aws:region  us-east-1
baseurl     value

luke:~/dd/pulumidemos/myproject
$ pulumi config set myproject:baseurl2 value2

luke:~/dd/pulumidemos/myproject
$ pulumi config
KEY         VALUE
aws:region  us-east-1
baseurl     value
baseurl2    value2
r
Understand. I currently didn’t use the same term for the prefix and the project name, so
myproject
was a bit misleading. This basically means it doesn’t matter if I provide
therealprojectname:
as prefix as this is used if the key is not namespaced. If I use
someotherprefix:
this will create a different namespace which is technically the same as
aws
?
So I’ll stick to non-namespaced keys for now.
This also means calling my pulumi project
aws
would not be the best idea 🙂
w
So I’ll stick to non-namespaced keys for now.
Yes - that's generally recommended for application config.
This also means calling my pulumi project
aws
would not be the best idea 🙂
Indeed - that's the core flaw of this approach unfortunately.
r
All right. Understood. Thanks a lot for clarifying!