adding support for switches: Force,AllowClobber,SkipPublisherCheck

[mrhockeymonkey]

This is to resolve issue #327

Not very much interesting, simply adding support for the switches used in PackageManagement.

[msftclas]

All CLA requirements met.

[jianyunt]

First thank you very much for your PR. Here are my comments:

1. any reasons you want to explicitly call out these parameters instead of using the existing $AdditionalParameters to pass them in?
2. this DSC resource is a kind of generic for all OneGet providers. My concern is that not all the OneGet providers support force, AllowClobber, SkipPublisherCheck. If people choose to use other providers and this dsc resource, their scenario will be broken, right?

[mrhockeymonkey]

1. I did first try specifying these switches using $AdditionalParameters like this :

AdditionalParameters = @{
    Force = $true
}

However this threw errors when trying to convert the value to a switch. I believe this is because $PSBoundParameters is a key value store but switches don't take a value they are a bit special. This issue is also reported by others (#327)

2. this is a good design in principle. But it also means that if other providers have switches we will not be able to use them. I've been trying to find a better way to pass switches (something like $AdditionalSwitches) in but without much success so far

[jianyunt]

@brywang-msft any ideas in the PM DSC module regarding AdditionalParameters ?

[mrhockeymonkey]

I've just learnt that -AllowClobber doesn't exist for cmdlets in PackageManagement in WMF 5.0, looks like it is only present in 5.1 which means this approach I have wont work.

I'm happy if you want to close this.

[jianyunt]

Correct AllowClobber does not exist in PackageManagement. It was added in PowerShellGet - a PackageManagement provider. Thanks @mrhockeymonkey.

[mrhockeymonkey]

Apologies for reopening this. I think there is a bit of confusion over where updates to the package management DSC resources should live. We decided in this PR above that the DSC Resource should be generic which led me to open a PR (PowerShell/PackageManagementProviderResource#40).

However ive just seen that someone else has also done so (PowerShell/PackageManagementProviderResource#39) to which you have directed him back to this repo?

It seems to me that if the PackageManagementProviderResource repo is now deprecated we should pull the PSModule DSCResource into this repo? would you agree? I'm happy to add that to this PR if so along with the original fix.

[jianyunt]

@mrhockeymonkey Yes PackageManagementProviderResource repo is deprecated. Use this repo going forward. Sorry for keeping asking you to submit the PRs back and forth. Our thinking was to ask users to use the generic DSC MSFT_PackageManagement. That's why we did not port the MSFT_PSModule DSC resource. However it looks like folks are already using MSFT_PSModule. I think we should consider porting the MSFT_PSModule from PackageManagementProviderResource to PackageManagement here too.

Yes it would be great if you can

1. Port the MSFT_PSModule DSC here and add your fixes to the MSFT_PSModule. Remove the changes in MSFT_PackageManagement.
2. Could you please integrate the changes from @brwilkinson Added the AllowClobber parameter to the PSModule resource PowerShell/PackageManagementProviderResource#39 too?
3. please update mof, mfl too
4. @brwilkinson, did you mention there is a bug in $AdditionalParameters in MSFT_PackageManagement DSC https://github.com/PowerShell/PackageManagementProviderResource/blob/master/DSCResources/MSFT_PackageManagement/MSFT_PackageManagement.psm1#L350? We should use $AdditionalParameters.GetEnumerator()) instead?
   If so, I recommand whether we can fix all together in this PR?

cc @JKeithB @edyoung

[brwilkinson]

@jianyunt There was actually additional work needed there. Which is why I went back to updating the original changes that I had made on PSModule. So the it would need further review before making any changes/decisions on the PackageManagement resource.

[mrhockeymonkey]

@jianyunt sounds good to me. would it make sense for me to start over with a fresh PR or do you want to keep this one for open for the discussion?

UPDATE: Upon starting this I see that the PSModule Resource uses the PowerShellGet module.

$moduleFound |  PowerShellGet\Install-Module -ErrorVariable ev

So this would introduce a cross module dependency. Not sure how i missed this the first time but on seeing this i think this repo is the best place for PSModule resource to live

https://github.com/PowerShell/PowerShellGet

Didn't realize these were separate module because of the similar naming i guess. Do you agree? This keeps the packagemanagement module generic as you had wished.

[jianyunt]

@brwilkinson thanks for you update and digging into it further. No worries we can migrate the psmodule dsc here first.

[jianyunt]

@mrhockeymonkey, yes PSModule DSC uses PowerShellGet. we have an few options:

1. All of the bug fixes in PSModule DSC goes to the https://github.com/PowerShell/PackageManagementProviderResource repo although it's deprecated. We can consider publishing hotfixes only.
2. PSModule DSC goes to PowerShellGet? CC @bmanikm
3. Users have to migrate their dsc to the generic PackageManagement DSC.
4. Move it here. if so PackageManagement module and PowerShellGet will have cross dependency. Also PackageManagement do not seem to be cohesive.

[mrhockeymonkey]

I would probably favor option 2 as it seems the most sensible. Sorry i haven't replied, i was waiting for a response from @bmanikm before I do go ahead in case I end up confusing matters more.

[bmanikm]

I agree PSModule DSC Resource should be part of the PowerShellGet module. Similarly, PSScript DSC Resource is required for the script items.

[jianyunt]

Cool! Thanks @bmanikm.
@mrhockeymonkey, you may consider submitting a PR to https://github.com/PowerShell/PowerShellGet. Please add your fixes to the MSFT_PSModule in your PR. Thank you for your help!

[alerickson]

Closing due to PR being moved to https://github.com/PowerShell/PowerShellGet/pull/347

[jrykowski-huron]

Closing due to PR being moved to https://github.com/PowerShell/PowerShellGet/pull/347

Getting a 404 on that pull 347 link.

This doesn't appear to have been merged to the master branch yet? It's a blocking issue for rollout of DSC for our work.