Simplify configuration

[iwahbe]

Implement the simplified configuration as described in #143 with the following caveat:
To ensure we call the right config.Try* function, type information needs to be available for config values.
Type information can be derived from the default value, if available, but if no default value is supplied then the type field is required.

If/When we add program level type checking, we can relax the required for type to be supplied.

Fixes #143

Depends on pulumi/pulumi#9407.

• Make sure to use the ENV variable to correctly call pulumi.ToSecret on config items marked secret.
• Add back the Secret option

[AaronFriel]

Interesting - acceptance test failures.

[AaronFriel]

Test failures on running the integration tests. Looks like something happened with asset conversion?

[iwahbe]

The test failures are from updating the version of pulumi/pulumi being pointed to. This includes an update to programgen. I'll have an updated test suite soon.

[AaronFriel]

This variable name isn't declared/assigned to, looks like a regression.

Funnily enough, the diff highlights that this didn't work before, either. It just also doesn't work after.

[AaronFriel]

I'm wondering if we should do this validation at all. If we evaluate config as an expression and not a string to be parsed, it can be anything, string, number, bool, array, object.

[AaronFriel]

Ah

[AaronFriel]

Looks good to me. Can you create an issue to track the nested interpolate expression in pulumi/pulumi.

The blocker for inferring configuration types in toto is the lack of global type checking and tracking types, yeah?

[iwahbe]

Looks good to me. Can you create an issue to track the nested interpolate expression in pulumi/pulumi.

The blocker for inferring configuration types in toto is the lack of global type checking and tracking types, yeah?

Issue created: pulumi/pulumi#9445

I see two problems that lead to a non-ideal configuration experience. Both related to typing. Config values must be typed, so we know what config.Try* function to call.

1. Because of the lack of global type analysis, we can't infer what type a config value should be. This requires a type field to allow the user to specify the type. Such a field would not be necessary if would could infer the type of the config value from where the value is used. I added local type analysis on the default value, so if a default value is supplied then we can infer the type of the configuration value. To obviate the need for the type field where a default value is not desired would require global type checking and unification.
2. We don't have a sufficiently expressive language to describe types. In an ideal world, our users would be able to specify

configuration:
  persons:
    type:
      Map:
        key: String
        value: 
          Object:
            name: String
            age: Number

We could then infer that { "person1": { "name": "me", "age": 42 } } is valid for persons but [ { "name": "me", "age": 42 } ] is not.

I hope that (2) can be implemented as an extension of our hierarchical config work.