From d2809f10b518b7eeebc897ccaf627741cf1da8b7 Mon Sep 17 00:00:00 2001 From: Chet Husk Date: Mon, 22 Jan 2024 14:41:38 -0600 Subject: [PATCH 1/2] Add proposal for a workload packagetype for NuGet --- accepted/2024/workload-nuget-packagetype.md | 79 +++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 accepted/2024/workload-nuget-packagetype.md diff --git a/accepted/2024/workload-nuget-packagetype.md b/accepted/2024/workload-nuget-packagetype.md new file mode 100644 index 000000000..00ba6bcbc --- /dev/null +++ b/accepted/2024/workload-nuget-packagetype.md @@ -0,0 +1,79 @@ +# **Create a new NuGet PackageType for Workloads-related packages** +- [baronfel](https://github.com/baronfel) +- N/A (will replace later) + +## Summary + +This spec proposes to add a new member to the set of known [PackageTypes](https://github.com/NuGet/NuGet.Client/blob/bd0764b4a5b78eea77c61f5b82078623c4fc0cfe/src/NuGet.Core/NuGet.Packaging/Core/PackageType.cs#L15-L20) to identify .NET SDK Workloads-related packages, and elaborate on how that new known PackageType will be used by the NuGet client and various other .NET Tooling that interacts with packages. + +## Motivation + +Workloads have been a key part of the .NET experience for the past 3 major versions, and over that time key .NET platform features have been added to the set of known workloads, and new workloads concepts like workload sets have been added. New tooling experiences like Aspire and MAUI, and new platforms like WASM, are purely distributed as Workloads. + +As a result, workloads-related packages have proliferated on NuGet.org, and in highly-searched areas like Aspire and MAUI the workloads-related packages often drowned out other user-facing packages that are more relevant to the user's search. + +If NuGet has a first-class idea of what a Workloads-related package is, it can use that information to improve the search experience for users, and ensure that NuGet clients that interact with workloads are correctly scoping their queries. Today, searching NuGet.org for `MAUI` returns 2688 packages, and of the first 10 results 8 are workloads packages that a user would never install as a PackageReference. This makes it much hard to discover MAUI-compatible packages. + +## Explanation + +### Functional explanation + + +Imagine NuGet had this filter. When an end user queries NuGet for a package using `dotnet package search` they only ever see packages that can be installed in their project! This is a huge win for the end user as they no longer have to sift through packages that are not relevant to them. + +Similarly, when a user runs `dotnet workload search` they only see workload packs that are known to their feeds - guaranteed. + +Also, when a user searches through NuGet.org, or the Visual Studio experiences, they can choose to filter out Workloads-related packages if they are not interested in them - this could even be the default, as the SDK team is quite convinced that users should never be interacting with Workloads-related packages directly. + +Finally, when a user views details for a Workloads-related package on NuGet.org, the UI would be able to hide the 'package manager installation' section, as this is never correct for workload packages, and computing the correct `dotnet workload install` command would require a lot of work at ingestion-time from NuGet (which we explicitly don't want to ask for). + +### Technical explanation + +There would need to be a number of stages to this work: +* The new PackageType would need to be defined in [NuGet.Packaging](https://github.com/NuGet/NuGet.Client/blob/bd0764b4a5b78eea77c61f5b82078623c4fc0cfe/src/NuGet.Core/NuGet.Packaging/Core/PackageType.cs#L15-L20) +* Workload authoring would have to be updated to include the new PackageType in the NuSpecs generated for all workload packages - this happens in [dotnet/arcade](https://github.com/dotnet/arcade) mostly. +* Separately, experiences could start to use the new package type + * `dotnet workload search` + * `dotnet package search` + * VS NuGet UI + * VSCode NuGet UI + * NuGet.org search + +## Drawbacks + +We shouldn't do this because it would be a new field that that non-NuGet.org servers would have to understand and process. + +## Rationale and alternatives + + + + + +This is a good design because it integrates nicely with the existing PackageType concept, recognizes a class of package that is fundamental to the ecosystem, important to organizational goals, and almost guaranteed to grow more in the future. + +Other designs might codify patterns outside of NuGet itself (like naming conventions, or hijacking metadata in the NuSpec) that would make it more difficult to standardize the behavior across the ecosystem. + +## Prior Art + + + +Other types of packages have gotten this same treatment in the past: +* .NET SDK Tools +* .NET SDK Templates + +These similarly are foundational to the way the .NET ecosystem works and are worth filtering (either out or in). + + + + + +## Unresolved Questions + + + + + +## Future Possibilities + + +I've laid this out a bit above, but I think different package search experiences in the ecosystem could start explicitly excluding workload packages ASAP once this is merged. From af1d48eba15acec476dfd5fe3be28a577cc0f8cb Mon Sep 17 00:00:00 2001 From: Chet Husk Date: Fri, 2 Feb 2024 08:59:17 -0600 Subject: [PATCH 2/2] rename and update file --- ...ery-changes-for-dotnetplatform-packages.md | 59 ++++++++++++++ accepted/2024/workload-nuget-packagetype.md | 79 ------------------- 2 files changed, 59 insertions(+), 79 deletions(-) create mode 100644 accepted/2024/gallery-changes-for-dotnetplatform-packages.md delete mode 100644 accepted/2024/workload-nuget-packagetype.md diff --git a/accepted/2024/gallery-changes-for-dotnetplatform-packages.md b/accepted/2024/gallery-changes-for-dotnetplatform-packages.md new file mode 100644 index 000000000..cd2259002 --- /dev/null +++ b/accepted/2024/gallery-changes-for-dotnetplatform-packages.md @@ -0,0 +1,59 @@ +# **Behavioral changes in Gallery for DotnetPlatform Packages** +- [baronfel](https://github.com/baronfel) +- N/A (will replace later) + +## Summary + +This spec proposes to make two behavioral changes to the Gallery for Packages that use the `DotnetPlatform` [PackageType](https://github.com/NuGet/NuGet.Client/blob/bd0764b4a5b78eea77c61f5b82078623c4fc0cfe/src/NuGet.Core/NuGet.Packaging/Core/PackageType.cs#L15-L20) to identify .NET SDK Workloads-related packages. These changes are intended to reduce user confusion and improve the suitability of NuGet.org search results for terms that overlap with terms present in Workload-related packages. + +## Motivation + +Workloads have been a key part of the .NET experience for the past 3 major versions, and over that time key .NET platform features have been added to the set of known workloads, and new workloads concepts like workload sets have been added. New tooling experiences like Aspire and MAUI, and new platforms like WASM, are purely distributed as Workloads. + +As a result, workloads-related packages have proliferated on NuGet.org, and in highly-searched areas like Aspire and MAUI the workloads-related packages often drowned out other user-facing packages that are more relevant to the user's search. + +The SDK team believes that a) workload packages are not intended to be directly installed by users, instead being installed by proxy through the `dotnet workload install` and/or `dotnet workload restore` commands, and b) most users are not interested in seeing workload packages in their search results, because they are typically looking for support packages for MAUI, Aspire, etc. instead of the raw implementation packages. + +Because workload packages are published with the `DotnetPlatform` `PackageType`, NuGet has a first-class idea of what a Workloads-related package is and it can use that information to improve the search experience for users. Today, searching NuGet.org for `MAUI` returns 2750 packages, and of the first 10 results 8 are workloads packages that a user would never install as a PackageReference. This makes it much hard to discover MAUI-compatible packages as an end user. + +## Explanation + +### Functional explanation + +Concretely, we'd like to suggest two orthogonal changes to the way the NuGet gallery treats `DotnetPlatform` packages: + +1) change the default free-form search filter to filter out `DotnetPlatform` packages + a) this implies adding a new filter to the search UI that allows users to opt-in to seeing `DotnetPlatform` packages in their search results, like .NET Tool and Template packages are today + b) we would need a new filter for `DotnetPlatform` packages explicitly so that devs could still locate specific package detail pages if they needed to, for example a .NET platform developer wanting to get a direct link to nuget.info for a package to investigate package contents or metadata + +2) change the rendering behavior for `DotnetPlatform` packages on the package details page to remove the 'package manager installation' section, as this is never correct for workload packages + a) in the future this could be changed to offer a `dotnet workload install` command that would result in this package getting installed, but this is a surprising amount of work to discover and we don't want to ask for it without further end-user signal + + +### Technical explanation + +* The Gallery will add a new filter to the search UI that allows users to opt-in to seeing `DotnetPlatform` packages in their search results, like .NET Tool and Template packages are today +* The Gallery will change the rendering behavior for `DotnetPlatform` packages on the package details page to remove the 'package manager installation' section, as this is never correct for workload packages +* The Gallery will change the default filters for server-side search to exclude `DotnetPlatform` packages by default, unless the `&packagetype=dotnetplatform` query parameter is explicitly appended. + +## Drawbacks + +Users may be confused by the new behavior, and may not understand why they can't find a package they know exists on NuGet.org. This is mitigated by the fact that the new behavior is opt-in, and the new behavior is consistent with the behavior of other package types like .NET Tool and Template packages. + +## Rationale and alternatives + +This is a good design because it integrates nicely with the existing PackageType concept, recognizes a class of package that is fundamental to the ecosystem, important to organizational goals, and almost guaranteed to grow more in the future. + +Other designs might codify patterns outside of NuGet itself (like naming conventions, or hijacking metadata in the NuSpec) that would make it more difficult to standardize the behavior across the ecosystem. + +## Prior Art + +Other types of packages have gotten this same treatment in the past: +* .NET SDK Tools +* .NET SDK Templates + +These similarly are foundational to the way the .NET ecosystem works and are worth filtering (either out or in). + +## Unresolved Questions + +## Future Possibilities diff --git a/accepted/2024/workload-nuget-packagetype.md b/accepted/2024/workload-nuget-packagetype.md deleted file mode 100644 index 00ba6bcbc..000000000 --- a/accepted/2024/workload-nuget-packagetype.md +++ /dev/null @@ -1,79 +0,0 @@ -# **Create a new NuGet PackageType for Workloads-related packages** -- [baronfel](https://github.com/baronfel) -- N/A (will replace later) - -## Summary - -This spec proposes to add a new member to the set of known [PackageTypes](https://github.com/NuGet/NuGet.Client/blob/bd0764b4a5b78eea77c61f5b82078623c4fc0cfe/src/NuGet.Core/NuGet.Packaging/Core/PackageType.cs#L15-L20) to identify .NET SDK Workloads-related packages, and elaborate on how that new known PackageType will be used by the NuGet client and various other .NET Tooling that interacts with packages. - -## Motivation - -Workloads have been a key part of the .NET experience for the past 3 major versions, and over that time key .NET platform features have been added to the set of known workloads, and new workloads concepts like workload sets have been added. New tooling experiences like Aspire and MAUI, and new platforms like WASM, are purely distributed as Workloads. - -As a result, workloads-related packages have proliferated on NuGet.org, and in highly-searched areas like Aspire and MAUI the workloads-related packages often drowned out other user-facing packages that are more relevant to the user's search. - -If NuGet has a first-class idea of what a Workloads-related package is, it can use that information to improve the search experience for users, and ensure that NuGet clients that interact with workloads are correctly scoping their queries. Today, searching NuGet.org for `MAUI` returns 2688 packages, and of the first 10 results 8 are workloads packages that a user would never install as a PackageReference. This makes it much hard to discover MAUI-compatible packages. - -## Explanation - -### Functional explanation - - -Imagine NuGet had this filter. When an end user queries NuGet for a package using `dotnet package search` they only ever see packages that can be installed in their project! This is a huge win for the end user as they no longer have to sift through packages that are not relevant to them. - -Similarly, when a user runs `dotnet workload search` they only see workload packs that are known to their feeds - guaranteed. - -Also, when a user searches through NuGet.org, or the Visual Studio experiences, they can choose to filter out Workloads-related packages if they are not interested in them - this could even be the default, as the SDK team is quite convinced that users should never be interacting with Workloads-related packages directly. - -Finally, when a user views details for a Workloads-related package on NuGet.org, the UI would be able to hide the 'package manager installation' section, as this is never correct for workload packages, and computing the correct `dotnet workload install` command would require a lot of work at ingestion-time from NuGet (which we explicitly don't want to ask for). - -### Technical explanation - -There would need to be a number of stages to this work: -* The new PackageType would need to be defined in [NuGet.Packaging](https://github.com/NuGet/NuGet.Client/blob/bd0764b4a5b78eea77c61f5b82078623c4fc0cfe/src/NuGet.Core/NuGet.Packaging/Core/PackageType.cs#L15-L20) -* Workload authoring would have to be updated to include the new PackageType in the NuSpecs generated for all workload packages - this happens in [dotnet/arcade](https://github.com/dotnet/arcade) mostly. -* Separately, experiences could start to use the new package type - * `dotnet workload search` - * `dotnet package search` - * VS NuGet UI - * VSCode NuGet UI - * NuGet.org search - -## Drawbacks - -We shouldn't do this because it would be a new field that that non-NuGet.org servers would have to understand and process. - -## Rationale and alternatives - - - - - -This is a good design because it integrates nicely with the existing PackageType concept, recognizes a class of package that is fundamental to the ecosystem, important to organizational goals, and almost guaranteed to grow more in the future. - -Other designs might codify patterns outside of NuGet itself (like naming conventions, or hijacking metadata in the NuSpec) that would make it more difficult to standardize the behavior across the ecosystem. - -## Prior Art - - - -Other types of packages have gotten this same treatment in the past: -* .NET SDK Tools -* .NET SDK Templates - -These similarly are foundational to the way the .NET ecosystem works and are worth filtering (either out or in). - - - - - -## Unresolved Questions - - - - - -## Future Possibilities - - -I've laid this out a bit above, but I think different package search experiences in the ecosystem could start explicitly excluding workload packages ASAP once this is merged.