PSRepository: New DSC resource

[johlju]

I suggest we add a new DSC resource PSRepository to this module. Initially the new resource should be able to register a new PowerShell repository (Register-PSRepository), remove a registered repository (Unregister-PSRepository) and change properties of a an already registered repository (Set-PSRepository).
The permission to add, remove or change the repository is controlled by the built-in PsDscRunAsCredential property.

I suggest the following schema for the new resource.

[ClassVersion("1.0.0.0"), FriendlyName("PSRepository")]
class MSFT_PSRepository : OMI_BaseResource
{
    [Key, Description("The name of the repository to manage.")] String Name;
    [Write, Description("If the repository should be present or absent on the server being configured."), ValueMap{"Present","Absent"}, Values{"Present","Absent"}] String Ensure;
    [Write, Description("Specifies the URI for discovering and installing modules from this repository. A URI can be a NuGet server feed, HTTP, HTTPS, FTP or file location.")] String SourceLocation;
    [Write, Description("Specifies the URI for the script source location.")] String ScriptSourceLocation;
    [Write, Description("Specifies the URI of the publish location. For example, for NuGet-based repositories, the publish location is similar to http://someNuGetUrl.com/api/v2/Packages.")] String PublishLocation;
    [Write, Description("Specifies the URI for the script publish location.")] String ScriptPublishLocation;
    [Write, Description("Specifies the installation policy. Valid values are: Trusted, UnTrusted. The default value is UnTrusted.", ValueMap{"Trusted", "Untrusted"},Values{"Trusted", "Untrusted"}] String InstallationPolicy;
    [Write, Description("Specifies a OneGet package provider. Default value is 'NuGet'.")] String PackageManagementProvider;

I can put in the work for this resource if the community/team is interested by this addition.

[bgelens]

Maybe check this out first? https://github.com/OneGet/oneget/tree/master/src/Microsoft.PackageManagement.DscResources

[johlju]

Ah, actually did not know about that one! Thanks for pointing that out. Make sense that the resource is in that repo. Better extending that repo instead then?

[bgelens]

I don't know :) I just remembered this repo from a couple of years ago and looked it up just now only to figure out it was discontinued and moved to the other repo.

[PlagueHO]

Our teams tried to use that one at work. But it does need some work to make it work properly with PS. It is probably worth building completely new over in this project.

[johlju]

@alerickson what is your view around this?
I wouldn’t mind building a new resource here with proper tests.

[alerickson]

@johlju I would suggest building the resource here. I think it'd be a little more straightforward and seems more appropriate given the functionality is to interact with with PS repositories.

[johlju]

I will start work on this resource this weekend.

[johlju]

I have this ready to be sent in, but we need to wait for the PR #424 to be merged as there are dependencies in that PR.
https://github.com/johlju/PowerShellGet/tree/add-psrepository

[alerickson]

Hi @johlju, after talking to a couple of folks on the DSC resource team, I'm trying to understand the advantages/disadvantages of having the resource here vs it being its own separate module. I'm pretty new to DSC resources in general so I'd love to hear your thinking behind this.

[johlju]

@alerickson the benefit I see is that the resources will be present on (Windows) servers in the future if the PowerShellGet module (including the resources) is signed and bundled with Windows (client and server). Having the resource already on Windows (in the future) will make sure there is a easy way of downloading modules from the Gallery without first manually updating the PowerShellGet module (or another module). But if the resources would be in another DSC resource module, for example ComputerManagementDsc, then LCM supports downloading that resource module from the users private location (share, etc). The advantage would be that these two resources would be bundled in Windows in the future they would basically be "built-in" from that Windows version and beyond.
A disadvantage is that it would be a "breaking change" if they would not be there for a future Windows build.
Since the resources are not cross-platform (since DSC does not yet work on PS Core) the resources can currently only be used on Windows. This could be solved as soon as there is support for DSC in PS Core.
Another (maybe) "disadvantages" is that the resources here need to be documented in PowerShell Docs, which is an issue I was about to raise as soon as they were released, so I could get that done too.

My first thought when looking at a way to easily download a module from a private or public gallery using DSC was to add a similar module to the resource module ComputerManagementDsc. When there already was a first iteration of PSModule in this repository I thought that the benefit mentioned above was the general idea, so I started making sure the resource here would be properly tested so it could be released.
After that I thought we needed a way to download a module from a private repository too, hence the PSRepository resource.

So the only benefit I see is that the resources here (PSModule and PSRepository) will be bundle with Windows in the future so they are built-in. If they will not, then there is no point of having them here, but instead they should be moved to the ComputerManagementDsc which is part of the DSC Resource Kit (PowerShell DSC Team).

Actually, if in the possibility that the resources would not be released I would move them to the resource module ComputerManagementDsc.
So if the conclusion is that they do not fit in this module I will be happy to move them to the repo ComputerManagementDsc so they can be released in the next release cycle.

/cc @PlagueHO if he sees other advantages/disadvantages of having PSModule and PSRepository here.

[alerickson]

@johlju no need to move it! After doing a bit more research and taking in your input I think this is definitely the appropriate home for the resources. I know the PRs are merged already, but I was wondering if you could move PowerShellGet.LocalizationHelper.psm1 and PowerShellGet.ResourceHelper.psm1 into a different folder so that they don't need to be signed with the release. Otherwise everything looks great!

[johlju]

@alerickson I can move the helper modules, but a few questions

1. Doesn’t them need to be signed as well if signed code (the resources) are using the helper functions?
2. Do they need to move in the repo, or just in the published artifact, or both?
3. Where do you need them to be moved so they don’t have to be signed?