Add support for internal PS repositories

[iainbrighton]

Lability currently only supports the PS Gallery, Github and Filesystem module "providers". If using an internal repository, e.g. ProGet or PSPrivateGallery, it would be great to be able to download modules from there too..

[iainbrighton]

Thinking out loud, here's what I think will work for everyone:

Phase 1

• We add a Set-LabHostDefault -PSRepositoryUri parameter
  • We default this to http://www.powershellgallery.com/api/v2/ to maintain existing PSGallery compatibility
  • If needed/required, this could be changed to support any internal (unauthenticated) Nuget PSRepository

Pros/Cons

• This would mandate that all required modules to be hosted on an internal repository
  • This might actually be a desired outcome for some?

Phase 2

• We add an additional Uri module PSGallery "Provider" property to support overriding individual modules
  • If this is not supplied, we default to the -PSRepositoryUri location (whatever that is)
  • To use an alternate PS repository, specify this in the module definition:

NonNodeData = @{
    Lability = @{
        DSCResource = @(
            ## Downloads from the host/default PSRepostory URI
            @{ Name = 'xNetworking'; RequiredVersion = '3.2.0.0'; }
            ## Downloads from a different PSRepostory URI
            @{ Name = 'xPSDesiredStateConfiguration'; Uri = 'http://MyInternalPSRepository.lab.local/api/v2/'; RequiredVersion = '6.0.0.0'; }
        )
    }
}

I'm not sure whether we just need host, i.e. https://www.powershellgallery.com - as the /api/v2 always required in the API call?

[rikhepworth]

Phase 1 would be exactly what I'm looking for - our ProGet server caches Powershell Gallery and I want to force use of that server. Since Lability downloads directly rather than using save-module it bypasses any settings we make for repositories.
Phase 2 is what I originally had in mind as I thought this would be the change with least impact - leave everything 'as is' and add a fourth module provider which can be pointed at a specified URL (or use save-module to take advantage of configured repositories).

I should add that many orgs I work with prefer to use their own repository for nuget and powershell as it allows teams to specify version of modules, hang on to older versions that may disappear from public repositories, and vet modules before making them available. This enhancement would be a great help for them.

[iainbrighton]

@rikhepworth Thanks for your input.

Do you have any views on whether the PSRepostoryUri parameter should be specified with or without the /api/v2 suffix? Does this part ever change based upon the repository? I assume not as it's a Nuget "thing"?

[rikhepworth]

@iainbrighton I can't answer that right now. I need to do some testing with our ProGet server. My current recollection is that we don't specify the /api/v2 suffix for download, but I need to check.