PowerShell / PowerShell-RFC

RFC (Request for Comments) documents for community feedback on design changes and improvements to PowerShell ecosystem
MIT License
429 stars 123 forks source link

Incremental Dynamic Parameter Bind #361

Open dkattan opened 11 months ago

dkattan commented 11 months ago

Summary

  1. Incremental Binding: As RuntimeDefinedParameter objects are written to the output in the dynamicparam block, they are immediately bound if an argument is available. This behavior differs from the current state, where all parameters are bound after the entire dynamicparam block has executed.

  2. Variable Creation: When a RuntimeDefinedParameter is bound, a variable with the name of that parameter should be created in the dynamicparam block scope. This makes the bound value immediately available for subsequent logic in the dynamicparam block.

I already have a PR with the required code changes: https://github.com/PowerShell/PowerShell/pull/20069  

Example

For brevity, this example assumes a user-supplied New-Parameter function.

Function Get-EdgeUpdates
{
    param()
    dynamicparam
    {   
        $EdgeVersions = Invoke-RestMethod https://edgeupdates.microsoft.com/api/products
        # Emit a RuntimeDefinedParameter to the pipeline
        New-Parameter -Name Product -ValidValues $EdgeVersions.Product -Type ([string]) -Mandatory
        # $Product is immediately available for use
        if($Product)
        {
            $EdgeReleases = $EdgeVersions | ?{$_.Product -eq $Product} | select -Expand Releases # Beta,Stable,Dev,Canary
            New-Parameter -Name Platform -ValidValues ($EdgeReleases.Platform | select -Unique) -Type ([string]) -Mandatory # Windows,Linux,MacOS,Android
            if($Platform)
            {
                $EdgeReleases = $EdgeReleases | ?{$_.Platform -eq $Platform}                
                New-Parameter -Name Architecture -ValidValues ($EdgeReleases.Architecture | select -Unique) -Type ([string]) -Mandatory # x86,x64,arm64,universal
                if($Architecture)
                {
                    $EdgeReleases = $EdgeReleases | ?{$_.Architecture -eq $Architecture}                
                    New-Parameter -Name Version -ValidValues ($EdgeReleases.ProductVersion | select -Unique) -Type ([string]) -Mandatory    
                }
            }
        }
    }
    end
    {
    }
}
dkattan commented 10 months ago

@SydneyhSmith When do things like this get reviewed? I would love to be part of the conversation.

SteveL-MSFT commented 8 months ago

@JamesWTruher can you see if the Engine WG can review this?

dkattan commented 8 months ago

@JamesWTruher can you see if the Engine WG can review this?

I'd really love to be a part of the conversation with the working group. This is a non-breaking change, only net new functionality but the last time they reviewed it I was told to create an RFC so I did.

dkattan commented 7 months ago

@SteveL-MSFT Community call is tomorrow, still looking for feedback on this.

IntegriComCalvin commented 7 months ago

I would really really like to have this feature. So much easier to write and I have several use cases.

homotechsual commented 7 months ago

Would love to see this in PowerShell it would open up some interesting and more complex use cases not possible with the current implementation.

gigacodedev commented 7 months ago

I could definitely find use in this, seems useful for complex multi-site automation tasks that may have a varying set of environments.

noaht8um commented 7 months ago

+1. Have some existing modules that use dynamic parameters which would be streamlined with this. This would also open the door for less confusion when it comes to writing user-driven PowerShell modules (i.e. a helper module for technical folks that are not necessarily PowerShell savvy). This would be awesome.

dszp commented 7 months ago

+1 This would make it substantially easier to deal with situations such as the example, which likely has equal application in dealing with the mess of versions and channels of Office/Apps for Business/Enterprise besides Edge, in another Microsoft example.

This would be helpful in automating both with larger scripting toolsets and in adding better validation to more complex system admin and management scripts, so I support the change.

immolate commented 7 months ago

Anything Darren writes generally makes my life easier as one of his customers. Please consider the changes and merge so many, MANY people can benefit from his recommendations. Thanks.

Dakota-LM commented 7 months ago

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

MWGMorningwood commented 7 months ago

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

I 100% agree with this- it seems like Darren is the one trying to make the name true here

etopple commented 7 months ago

I’d love to see this pushed into production. Would be super helpful.

dimitrirodis commented 7 months ago

So, net new functionality with no breaking changes. Sounds like a win. What's the problem?

jbbehar commented 7 months ago

Agree with all the above comments - can this be prioritized for inclusion ASAP? This PR is already months old.

JerBar commented 7 months ago

This would be a huge game changer for sure.

andrewqit commented 6 months ago

Add one more to the list that needs this!

tylernocwing commented 6 months ago

I hope this gets implemented dkattan

herringms commented 6 months ago

Very needed for partners

dlfoster311 commented 6 months ago

I think this would be a cool addition! It could make scripts way smarter by adapting on the fly as you define parameters.