Add proposal for filtering DotnetPlatform packages from Gallery serach by default

[baronfel]

After some discussion today with members of the SDK, MAUI, and Aspire teams, we think that for high-profile frameworks like MAUI/Aspire the NuGet.org search experience for users is muddled by the inclusion of Workload-related packages in the search results.

We think that given workloads are A Thing ™️ in the .NET Ecosystem at this point, it makes sense to filter them from the default search experience, as well as removing incorrect installation instructions from their display. Please let me know what you think!

Rendered Proposal

Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Thank You 🎉

[jonathanpeppers]

Would we also show some dotnet workload command here on NuGet.org?

The command it's suggesting here for this workload pack... would not work.

[baronfel]

Frankly I'd suggest showing nothing there for workload-related packages. If we did show anything we'd have to somehow detect which top-level workload a particular package belonged to, and that would involve parsing workload content which is a thing the NuGet team may not be inclined to do.

[jonathanpeppers]

Yeah as long as dotnet add package goes away, that seems good enough to me. 👍

[JonDouglas]

Straight-forward proposal to me. I think the only thing missing is what is the proposed PackageType naming for the workloads type? Are you proposing any specific name here or should we just call it Workloads or DotnetWorkloads?

[jonathanpeppers]

There are already workload packages today, that have PackageType=DotnetPlatform.

Example: https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.Mono.android-arm64

I believe all current workload packages are this way.

[baronfel]

@JonDouglas do you have any insight into the other packages that use this existing PackageType? would it massively negatively impact those packages (if any) if NuGet.org made a change to the default search filters?

[JonDouglas]

@baronfel We can detect the DotnetPlatform packagetype and even add it to be more prominent on nuget.org. Today I don't think we even recognize it although you could technically filter it:

https://www.nuget.org/packages?q=&packagetype=DotnetPlatform&prerel=true&sortby=relevance

So now that I understand these already have a packagetype, what type of experience are we wanting here? For these workload packages to move to a new packagetype, for us to recognize DotnetPlatform as a filter, or something else?

Here's more thoughts now:

1. If we had a workload packagetype, it would be easier to differentiate platform and workload packages. Can I ask a dumb question? Is this a thing? Are there platform packages that aren't workloads or vice versa? Are all foundational elements of .NET platform part of workloads in other words?
2. With whatever resulting packagetype, we can provide better installation instructions on package details screen and also add a filter option for it on NuGet.org.

The question i have now is if we need a new packagetype or if we just reuse the existing one. I don't have a good answer on that one.

[baronfel]

@JonDouglas if y'all are down for it, something like

• workloads get authored with the DotnetPlatform packagetype
• NuGet.org search filters out DotnetPlatform packages by default
• NuGet.org search allows for opting in to DotnetPlatform packages by some kind of checkbox/radio button in search results (possible today but the DotnetPlatform packagetype is not currently shown on the filter)

There are 75 packages that aren't authored by Microsoft that have this package type already, but those mostly seem to be in the bucket of 'users cannot install this directly' already, so it seems correct to filter this.

[JonDouglas]

@JonDouglas if y'all are down for it, something like

• workloads get authored with the DotnetPlatform packagetype
• NuGet.org search filters out DotnetPlatform packages by default
• NuGet.org search allows for opting in to DotnetPlatform packages by some kind of checkbox/radio button in search results (possible today but the DotnetPlatform packagetype is not currently shown on the filter)

There are 75 packages that aren't authored by Microsoft that have this package type already, but those mostly seem to be in the bucket of 'users cannot install this directly' already, so it seems correct to filter this.

sounds reasonable to me but let's let some others chime in here. we don't expect folks to be interfacing with these platform packages much in other words and want to hide them for now.

[anangaur]

Is there a usecase of searching or browsing workload packages on NuGet.org?

[baronfel]

Is there a usecase of searching or browsing workload packages on NuGet.org?

I don't believe so - the only way to reasonably search for workloads is via dotnet workload search, or another mechanism that can 'decrypt' the workload manifest <-> workload packs relationships. It's possible that the advertising manifests could show a useful interface on NuGet.org (e.g. the aspire manifest could show dotnet workload install aspire), but until we land workload sets each version of a manifest would always have the same command.

At the same time, there's no direct pointer in the NuGet metadata between workload packs and the manifest(s) they belong to, so there's not a reasonable way to link a pack to the dotnet workload command that would install it.

Together, this makes me want to remove them from general search entirely. They should be available to search in explicitly-selected DotnetPackage PackageType searches, and of course a specific package link should always be visible in the UI.

[JonDouglas]

Together, this makes me want to remove them from general search entirely. They should be available to search in explicitly-selected DotnetPackage PackageType searches, and of course a specific package link should always be visible in the UI.

Yep this sounds sensible. We may need to just revisit this proposal to include this then. If we head in this direction, maybe later down the line we would consider @jonathanpeppers proposals when we can actually point people to easy workload commands and make it easier to search for them if that time ever comes.

I could imagine in a while that there may be a "Workloads" category or search that lists popular workloads one can copy/paste the CLI command or get instructions on how to acquire in other tooling down the line.

[baronfel]

I've updated the spec to capture two distinct behavioral changes we'd like, both of with are focused on the Gallery. I've updated the description here to match as well.

[nkolev92]

You can link https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1213 as well, which is basically the install time failure if you attempt to install these packages.

That strengthens the case that these should be excluded from the default search.