[Feature]: Add hosting of PowerShell modules and scripts

[o-l-a-v]

Related Problem

PowerShell Gallery runs NuGet v2 and has various API issues that does not seem to get attention.

• 2018-10-01: IsAbsoluteLatestVersion is false for all versions in some packages PowerShell/PowerShellGallery#30
• 2023-10-27: PSGallery Search() Function doesn't page unless the top is 100 above the result count PowerShell/PowerShellGallery#241
• 2023-11-21: Find-PSResource does not sort versions properly PowerShell/PSResourceGet#1484
• 2024-03-24: API - Get with $select=Owners returns "an error has occurred" PowerShell/PowerShellGallery#267
• 2024-03-24: API - Some packages are not returned if semverlevel=2.0.0, but are returned if semverlevel=1.0.0 PowerShell/PowerShellGallery#268
• 2024-04-11: API - Filter by version - $filter=NormalizedVersion gt '9' does not return any newer major versions PowerShell/PowerShellGallery#269
• 2024-04-11: API - Filter by version - Specifying both minimum and maximum version returns no results PowerShell/PowerShellGallery#270
• 2024-05-15: filter IsLatestVersion returns invalid response for package Microsoft.PowerShell.PSResourceGet PowerShell/PowerShellGallery#273

And some other usability issues:

• 2019-04-01: No validation of version number mismatches between .nuspec and .psd1 PowerShell/PowerShellGallery#55
• 2021-11-08: Error 500 when trying to change email PowerShell/PowerShellGallery#202
• 2022-08-26: Not recieving email for password reset PowerShell/PowerShellGallery#234
• 2023-01-03: Verify Publisher of Azure AD Application (MSAL SSO) PowerShell/PowerShellGallery#245
• 2023-02-28: Contact owner feature not working PowerShell/PowerShellGallery#248
• 2023-06-01: Can't receive email address confirmation email PowerShell/PowerShellGallery#254
• 2023-08-19: Uploaded by ... PowerShell/PowerShellGallery#258
• 2023-12-15: 500 Error on Email Address Verification Link PowerShell/PowerShellGallery#265
• 2024-05-18: Email is revealed in "Package published" notification PowerShell/PowerShellGallery#275

Some feature requests for features NuGet gallery already have:

• 2021-11-29: Why don't we have repo-signing? PowerShell/PowerShellGallery#206
• 2022-03-14: nuget protocol v3 PowerShell/PowerShellGallery#218
• 2023-03-13: PowerShell Gallery Package Vulnerability Scanner PowerShell/PowerShellGallery#250

PowerShell Gallery seems to be maintained by a small team. I absolutely believe they are doing what they can, with the time and resources they have. But limited resources hurts speed of fixing issues, and thus reliability and quality.

Somewhat relevant: There are talks of moving Microsoft maintained modules to a public ACR (Azure Container Registry) instance and keep PowerShell Gallery as a host for community maintained resources.

Instead of keeping the PowerShell Gallery as a separate thing, why not just add PowerShell modules support to nuget.org?

The Elevator Pitch

PowerShell modules and scripts are also .nupkg files, only with a tag PSModule if a module, and PSScript if a script, to tell PSResourceGet & PowerShellGet that "this particular .nupkg file is indeed a PowerShell resource".

• Let the PowerShell community piggyback nuget.org, and thus get a much better API experience, better reliability, NuGet v3 backend etc.
• Let Microsoft maintain less public infrastructure. Probably can't kill PowerShell Gallery in a heartbeat though.

Can it be that much work to add that ability to the NuGet Gallery? 🤔 I don't know, which is why I ask.

Additional Context and Details

No response

[joelverhagen]

I think this question required organizational discussions in addition to technical discussions. As you stated, there are multiple Microsoft teams at play here with separate charter, infrastructure, primary goals, etc. I can't speak authoritatively for either NuGet team or PowerShell team in this regard. I am not in a leadership position, except perhaps technical leadership in NuGet. So I will raise some technical points that I am aware of and leave the organizational discussion to others on my team (as priority/availability allows). I am quite sure that the organizational discussion can't fully happen here on a GitHub issue. Those would likely happen with internal Microsoft communications between leadership, etc. etc. But this issue could perhaps be a starting point. I mention this all to temper expectations and say... this would not be a simple thing!

This is an interesting question, to be sure.

Here are some technical points I think should be understood:

PowerShellGallery is a fork of NuGetGallery, but has a lot of extra UX. For example, the command palette on the package details page has PowerShell-specific installation steps instead of .NET ecosystem steps. There is a file list + file content expandable section as well as a list of cmdlets. The search experience is a little different too, with operating system and category filtering. These are options that don't exist on NuGet.org and would either be lost or would somehow need to be ported. The package details enhancements could be easy if (isPowerShell) { // show PowerShell UI } but the search filters would feel awkward. We would have a union of .NET + PowerShell UX elements there. Confusing perhaps. PowerShell Gallery team would know the full extent of the delta they maintain since they do the forking operation, but this gap would need to be merged, refactored or dropping in a move to NuGet.org.

I know there are API differences too. The V2 API on PowerShellGallery has additional fields on the Packages entity like ItemType, FileList, GUID, PowerShellVersion, PowerShellHostVersion, DotNetFrameworkVersion, CLRVersion, ProcessorArchitecture, and CompanyName. Maybe others. V2 on NuGet.org is in maintenance mode (no enhancements) so we wouldn't want to do the work to merge PowerShell V2 into NuGet V2.

AFAIK, PowerShell .nuspec files (manifest inside the .nupkg) do not have a package type. Therefore, they would be assumed to be dependency packages by NuGet tooling. This is not good! Perhaps they could co-existing on NuGet.org with a package type fix-up.

NuGet.org has it's own namespace of package IDs and owner usernames. These would overlap in some cases with PowerShell Gallery. How would the collisions be resolved? There are also ID prefix reservations on NuGet.org which we wouldn't want to violate. Some ownership would overlap nicely, some would not.

NuGet.org repository signs packages and the NuGet client validates the signatures. Are we really okay with PowerShell tooling having a lower verification standard than NuGet? (i.e. PowerShell tooling does NOT require repository signatures from packages, AFAIK).

These are my rough thoughts. It doesn't seem impossible but there is a high degree of ambiguity that would need a lot of work to iron out.

@o-l-a-v, if you have thoughts or answers to any of these points, feel free to answer (no pressure at all, just wanted to clarify you are free to add your perspective to this ambitious idea). But otherwise, this can be a working list of open questions we can answer if we ever pick this idea up internally and push on it.

[o-l-a-v]

Thank you for the very valuable information and insight. 🙏🏻

Things are never as easy as you first think, sounds like more work and org decisions / politics than I first thought.

I have no solutions to the questions you asked, will edit this comment or post a new one if any new thoughts come to mind.

Will also be interesting to see if this discussion leads to anything down the line. Guess we'll let time do it's job and see if this sparks any initiatives.

---

One thought arised: I don't see how ACR (Azure Container Registry) is more suited to host PowerShell modules and scripts than NuGet Gallery.