PowerShellGet 3.0

[SteveL-MSFT]

Note, this includes breaking changes from PSGet v2. However, PSGet v2 users can continue to stay on v2.

[markekraus]

Edit: many of my initial concerns about this RFC have been addressed.

As PowerShell developer in a complex and matured PowerShell development environment, there are several key pain points with the current PowerShellGet that have forced our hands in completely moving away from it. If v3 can alleviate all of these pain points, we may consider not reinventing the wheel. As it stands, I'm not seeing enough in the RFC to change our current course.

First, working with authenticated repositories is a terrible experience both in automation (module CI/CD pipelines) and as a shell user (having Install-Module and Find-Module fail when one of your repositories requires authentication or having to enter a credential for every command). This goes for both installing from and publishing to such repos.

Second, there is no support for package-once-publish-many. I need to be able to get sha2 hashes from nupkgs before they are published to the repository and publishing multiple times results in slightly different sha2 hashes which will then cause sha2 mismatches between repositories.

Third, every time PowerShellGet publishes a new version of the PowerShellGet module it breaks our builds. There is insufficient tests in place to prevent regressions WRT to working with any repo that is not PowerShell Gallery. Every new version this year has costs us dozens of hours of productivity which we scramble to work around the issue or wait for an emergency release.

Fourth, the lack of built-in dependency management is painful. PSDepend is a great module, but it becomes an a priori dependency and we suffer a chicken and egg scenario. It (much like this RFC) also suffers from being in PowerShell configuration syntax. That is great for PowerShell, but in a mixed language environment it is a pain point. JSON would be better since there is better serialization and deserialization support in other languages and allows for consistent dependency management across languages and projects.

[kilasuit]

Oh Boy, this has been something that has been needed for while and I have lots to say on this RFC and downstream impact this will have.

I can see this being a very busy but much needed RFC

Thanks for kicking this off @SteveL-MSFT

[kilasuit]

This makes me sad @joeyaiello as this really needs to be prioritised into the v7 timeline as PowerShellGet is what I would define a critical module for any and all users of PowerShell.

I think that this really needs to be better prioritised and added into the PowerShell v7.0 consider pile as the timing of v7 and PowerShellGet v3 together would be a good coupling together

[KirkMunro]

.nupkg packages are supported in the GitHub Package Registry (which is currently in beta). I'm curious if/how that fits into these future PowerShellGet 3.0 plans.

[SteveL-MSFT]

Need to consider how to support meta packages that are cross platform. Consider a CommandCompleter meta module that includes TabExpansionPlusPlus and PSUnixUtilsCompleters as required modules. However, TabExpansionPlusPlus is mostly Windows centric and the other is Unix. No need to install both as RequiredModules and take up disk space when only one of them is used at runtime. Perhaps use PrivateData to indicate OS runtime for sub-modules and PSGetv3 will install only the one appropriate for the current OS. Save-Module would save the entire meta-module.

[jzabroski]

@SteveL-MSFT Why would you re-use an existing field, PrivateData, for something that is more like an extension? Is the idea that PrivateData would be a rich, hierarchical object?

RequiredModules is still broken, given that it doesn't allow specifying a DAG of module dependencies and can't gaurantee correct module load order.

The strange thing is that .NET Core Common Project System has already solved this problem (mostly) and collaborated with NuGet on various "representation independence" issuses. Suggest you grab a cup of cofee with Nick Guerrera and Nick Plaisted to discuss.

• I say mostly, because Nick still hasn't published the official specification for some parts of .NET Core, and there is a known issue where NuGet references don't allow you to specify an ExternAs alias for converting a NuGet Reference from a factory to a service locator. Jon Skeet covers some of these issues on his blog.

[jwittner]

As you move away from PackageManagement will the DSC resources in PowerShellGet be updated to reflect this? I don't see them called out specifically in the RFC, so just wanted to get a sense of the plan around them, and how they might be expected to change.

[Jaykul]

@SteveL-MSFT one other thing that we need to make sure happens is that if the users tries to Install and it fails because (for example) they failed to specify -NoClobber or -Force or whatever, they should not have to re-download it to try again...

[SteveL-MSFT]

Add -Nupkg type parameter to allow installing directly from a nupkg

[vexx32]

Can we get a full syntax diagram of proposed parameters & parameter sets?

It's a bit hard to see the full set from the RFC text as it is. 🙂

[iricigor]

As some time back I created POC for very similar functionality explained in this RFC (my module explanation), please allow me to have a couple of comments.

Specification - Local cache

1. "This will be a local json file (one per repository)"

The standard should not limit to one file but provide some extendable method. Currently, there are more than 50,000 commands on PS Gallery, and a number will increase. In my POC, I split local cache to multiple index files for faster queries. Query speed is critical if we want to have it attached to CommandNotFoundAction error handler.

Also, it might be good to split index file per each type of the object, i.e. have one file for modules, another one for commands, etc.

2. "The cache will be stored in the user path."

This will create the discrepancy between Windows and Linux. If I run 'sudo Update-PSCache' it will be stored under root profile, and other users running sudo commands will see it. If I run equivalent command on Windows, other administrator users or system accounts will not see it.

3. Repository administrator tools

If I create my own repository, I should have some "repository administrator tools" available for creating server-side cache inside my repo.

Updating resources

1. Update-PSResource

Update-PSResource must include also -WhatIf switch in order for users to be able to see what can be updated in advance. Or, there might be even some dedicated command to list updatable resources.

2. Update-PSResourceCache

I would suggest to include Update-PSResourceCache into the initial release. This functionality will be anyway implemented in the scope of other commands.

User Experience

1. Finding missing command should additionally address if a missing command is found in certain module and propose command Install-Module. It will be more acceptable by end-users than new command Install-PSResource

2. Does this RFC need to define what happens if a command is found in multiple places? For example, New-Password exists in about 8 different places.

[ThomasNieto]

PowerShellGet currently does not support script internalization. To add support the following minor changes can be made.

• Publish-PSResource for a script type resource will capture the ScriptName.psd1 in the root or language folder (en-US)
• Save-PSResource will land the script and language data file into the appropriate root or language folder

This work can also be expanded to include support for external help by performing the steps for the help xml files.

[SteveL-MSFT]

Thanks everyone for the feedback, but this RFC has been superseded by #237