Closed johlju closed 10 months ago
@gaelcolas @raandree @ykuijs @PlagueHO Do you know anything that could prevent this change from happening? For example using PSDepend specific functionality other than getting modules from a NuGet repository, e.g. PowerShell Gallery.
I currently do not see any issues. But before actually removing the PSDepend support, would it be an idea to first switch all repos to PSResourceGet and make sure they all work as expected?
Maybe we can switch on the top 5 most active ones of the DSC Community to not make it a to big of a job. But I am confident they will work. I already switched on SqlServerDsc.
The problem might be other repos (private ones) that might use parts of PSDepend (like fetching from a GitHub repository) that would break in the future if we remove PSDepend. Break when they updated the pipeline from the Plaster templates and functionality they used in PSDepend no longer works.
Another way would be to re-imagine PSDepend to use PSResourceGet or ModuleFast for the nuget part. But to big of a job for me to take on.
I hope community sees this issue and comments 😊
The PR #453 is proposing to switch the default method of the templates to PSResourceGet as a first step. It is still possible to change back to PSDepend and PowerShellGet in a generated module by disabling PSResourceGet in Resolve-Dependency.psd1.
Since PSResourceGet has been released (v1.0.1) and it is now supported by the pipeline (but is currently opt-in). Suggest removing PSDepend support and make PSResourceGet the default. It would simplify the code immensely.
The only issue with PSResourceGet is that is does not yet download dependencies from v3 repositories. That could be an issue when using Sampler's pipeline against other repositories than PSGallery, e.g. local repositories. It could be worked around by adding the dependencies to the RequiredModules.ps1 file.
ModuleFast is also supported, and would still be available for opt-in, but it requires PS v7.3 so that cannot be made the default.