Intent for this implementation - will it only be an Intermediate language?

[brwilkinson]

Summary of the new feature / enhancement

Shifting this to a new topic, since I originally put the below idea/comments in a different issue which was related to parallel execution only because I was tagged in that specific issue.

• https://github.com/PowerShell/DSC/issues/395#issuecomment-2048311646
  • The original concern was related to how we would do cross resource references for things like dependson.

I had seen some examples where multiple levels of nesting (of languages) e.g. functions are embedded in yaml or json and this was concerning for me, since it's not inviting for me to write/author and maintain. I can understand that if the intent was for this to be an intermediate language, then that would perhaps be required, however I wanted to get an idea on this up front.

Can we please plan now to have an authoring experience based on Bicep Language? People can still use yaml or json, however I feel like the advantages of Bicep is extremely compelling.

More on why I think this is important.

• Bicep utilizes "symbolic-name" for cross referencing resources
• Bicep has a rich set of functions, ~many~ most of which are implemented within Bicep itself and doesn't rely on the ARM engine
• Bicep is designed to build to json
• Bicep has custom types and an extensibility model
• simple/clean Bicep language for Configurations
  • avoids embedding other languages in json/yaml Etc.
• simple/clean Bicepparam files for ConfigurationData

Some examples

1) Radius have taken to extend Bicep in a way that would exactly meet the need that I am interested in this core tool of DSC to be extended.

• https://github.com/radius-project/radius
• https://github.com/radius-project/bicep 2) More specifically, here is a prototype for the extension of Bicep in a way that does not reply on ARM (Resource Manager) at all.
• https://github.com/anthony-c-martin/bicep-local-providers
  • Extension types included as part of this example/concept:
    • github
    • kubernetes
    • utils

example 2 above is the main reason for writing this thread/idea/feature request and I really hope this could get some traction

1) tagging @anthony-c-martin in case you can get the opportunity to chat with @SteveL-MSFT or @mgreenegit if you haven't had the chance to share each sides of your visions on Configuration Management. 2) I hope that it's possible for this to be more of a case of not if but when. 3) I know resources are limited, so perhaps this just becomes a community project up front?

Proposed technical implementation details (optional)

for simplicity I will link to the above utils sample in the:

• https://github.com/anthony-c-martin/bicep-local-providers/tree/main/samples/utils

using 'script.bicep'

// This sample only works on an OS with bash installed
param name = 'Anthony'
param platform = 'bash'

provider utils

param name string
param platform 'bash' | 'powershell'

resource sayHelloWithBash 'Script' = if (platform == 'bash') {
  type: 'bash'
  script: replace(loadTextContent('./script.sh'), '$INPUT_NAME', name)
}

resource sayHelloWithPowerShell 'Script' = if (platform == 'powershell') {
  type: 'powershell'
  script: replace(loadTextContent('./script.ps1'), '$INPUT_NAME', name)
}

output stdout string = (platform == 'bash') ? sayHelloWithBash.stdout : sayHelloWithPowerShell.stdout

[SteveL-MSFT]

Bicep has always been in our roadmap, but with limited resources won't on that won't happen til later unfortunately. One of the primary reasons we adopted ARM template syntax for the configuration doc is to eventually get to Bicep.

[mgreenegit]

@brwilkinson would you mind if we scheduled time for deeper discussion?

[brwilkinson]

@mgreenegit did you have a chance to talk with @anthony-c-martin?