PowerShellGet 3.0 #185
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.
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
Need to consider how to support meta packages that are cross platform. Consider a
@SteveL-MSFT Why would you re-use an existing field,
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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
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.
This will create the discrepancy between Windows and Linux. If I run '
If I create my own repository, I should have some "repository administrator tools" available for creating server-side cache inside my repo.
I would suggest to include
PowerShellGet currently does not support script internalization. To add support the following minor changes can be made.
This work can also be expanded to include support for external help by performing the steps for the help xml files.