So I'm afraid I know the answer to this, but...it ...
# general
b
So I'm afraid I know the answer to this, but...it looks like configuration data in Pulumi is just a string:string mapping?
m
That is essentially correct. It's currently up to the language to interpret the config values.
b
Nngh. That's really, really unfortunate
m
I think we have an issue somewhere tracking improving this. Looking...
b
(current context: "I have a list of CIDR blocks I need passed to a security group")
m
https://github.com/pulumi/pulumi/issues/1052 is the issue, though it sort of only hints at the problem.
b
Yeah, TBH this is the first part of Pulumi that I think I have to completely go around
m
The current approach is to represent richer values as JSON and use
config.requireObject<>
or
config.getObject<>
Yeah, the config system as it stands could use some work šŸ™‚
If you have ideas here we'd love to hear them.
b
I have ideas, but they fundamentally disrespect the multi-platform thing you're going for.
I'm probably just going to do the same thing I do for every other JS app:
require()
a file and throw if its export is not of type
MyStackConfig
.
m
šŸ‘
b
(When I say "JS" I really mean "TypeScript", and then I already have a self-describing config without having to have one reinvented)
Though, tangentially, the multi-language thing is the thing about Pulumi that worries me the most. Lowest common denominators and all
r
but... that was so easy to go around... that i'd call that a feature
s
I think Iā€™d agree with @rough-oil-1458 there.
b
I wouldn't, because now I'm not doing something standard.
Which means I have to document it and have to maintain it.
Users will read Pulumi's docs and have to remember (incurring additional cognitive load) that "we do something different here"
r
Library vs Framework šŸ™‚