Update NuGet Client SDK docs to include all published packages #3176
Conversation
|
Learn Build status updates of commit bd7727e: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
Thanks for the feedback, Andy. For the blog post I am working on internally, I need a document that lists all the packages published by the NuGet Client team. Unfortunately, I haven't found the right place. Perhaps we need a new documentation page to list all the packages our team publishes. |
Why? What benefit does it provide customers? Even if you proposed to put it in a blog post, I'd say it's not beneficial, but at least blog posts don't need to be kept up to date. But a docs page creates a maintenance burden, we need to remember to update the docs when we change which packages get published, so unless it provides customer value, I don't see the point. I'm thinking specifically about packages like NuGet.CommandLine.XPlat and NuGet.Build.Tasks, where there is no use case whatsoever that I can think of where downloading or using the package provides any benefit to customers. Honestly, there's no good reason for us to publish those packages to nuget.org either. I think it's just that our release scripts are simple (push NuGet.*.nupkg to nuget.org, without filtering out these "useless" packages that only exist because this is how we insert into the .NET SDK, but that uses a different feed, not nuget.org), and nobody found it valuable to add more logic into the release scripts to filter the packages to only the ones useful for customers. |
Co-authored-by: Andy Zivkovic <zivkan@users.noreply.github.com>
Co-authored-by: Andy Zivkovic <zivkan@users.noreply.github.com>
|
Learn Build status updates of commit 3f6a9a1: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
|
Learn Build status updates of commit 42ad6a0: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
|
Learn Build status updates of commit 7ce3685: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
| * [Exploring the NuGet v3 Libraries, Part 1: Introduction and concepts](http://daveaglick.com/posts/exploring-the-nuget-v3-libraries-part-1) | ||
| * [Exploring the NuGet v3 Libraries, Part 2: Searching for packages](http://daveaglick.com/posts/exploring-the-nuget-v3-libraries-part-2) | ||
| * [Exploring the NuGet v3 Libraries, Part 3: Installing packages](http://daveaglick.com/posts/exploring-the-nuget-v3-libraries-part-3) |
There was a problem hiding this comment.
I clicked on "Fix All Known Formatting Problems" in VS Code, which resulted in this change. I am happy to revert it if the team thinks this change should not be part of this PR.
I didn't see any difference in the rendered content between this change in the preview URL and the production URL.
|
|
||
| > [!Note] | ||
| > These blog posts were written shortly after the **3.4.3** version of the NuGet client SDK packages were released. | ||
| > Newer versions of the packages may be incompatible with the information in the blog posts. | ||
|
|
||
| Martin Björkström did a follow-up blog post to Dave Glick's blog series where he introduces a different approach on using the NuGet Client SDK to install NuGet packages: | ||
|
|
||
| - [Revisiting the NuGet v3 Libraries](https://martinbjorkstrom.com/posts/2018-09-19-revisiting-nuget-client-libraries) | ||
| * [Revisiting the NuGet v3 Libraries](https://martinbjorkstrom.com/posts/2018-09-19-revisiting-nuget-client-libraries) |
There was a problem hiding this comment.
I clicked on "Fix All Known Formatting Problems" in VS Code, which resulted in this change. I am happy to revert it if the team thinks this change should not be part of this PR.
I didn't see any difference in the rendered content between this change in the preview URL and the production URL.
Thank you for reviewing this PR. Your questions were valid and led me to realize that my understanding of the NuGet SDK was incorrect. I had assumed that any package published to nuget.org was part of the NuGet SDK, but this is not the case. I agree that creating a new docs page would unnecessarily increase maintenance without benefiting customers. I have accepted all your commit suggestions, and the PR is now ready for review.
I agree. Filed https://github.com/NuGet/Client.Engineering/issues/2582 issue. |
| @@ -11,11 +11,23 @@ ms.topic: conceptual | |||
|
|
|||
| The *NuGet Client SDK* refers to a group of NuGet packages: | |||
|
|
|||
| * [`NuGet.Protocol`](https://www.nuget.org/packages/NuGet.Protocol) - Used to interact with HTTP and file-based NuGet feeds | |||
| * [`NuGet.Packaging`](https://www.nuget.org/packages/NuGet.Packaging) - Used to interact with NuGet packages. `NuGet.Protocol` depends on this package | |||
| * [`NuGet.Indexing`](https://www.nuget.org/packages/NuGet.Indexing) - NuGet's indexing library for the Visual Studio client search functionality. | |||
There was a problem hiding this comment.
Why do we ship this again?
Is it VS4Mac?
There was a problem hiding this comment.
Great question. NuGet.org used by tab says https://github.com/mono/monodevelop repo is using this package, but it is marked as public archive.
https://searchcode.com/?q=NuGet.Indexing also points out monodevelop product using this package.
There was a problem hiding this comment.
Added NuGet.Indexing package to https://github.com/NuGet/Client.Engineering/issues/2582.
There was a problem hiding this comment.
monodevelop is what eventually became vs 4 mac, so sounds like yes is the answer.
There was a problem hiding this comment.
We have at least one person/partner, who I'm confident is not VS4M, using NuGet.Indexing: NuGet/Home#11388
Although given the version number they reported, it sounds like they're getting the package though Arcade/Maestro, not nuget.org. Anyway, if we want to effectively remove this package as part of the client SDK, then we should be aware that it will break some people who are using it.
There was a problem hiding this comment.
On the contrary, I'm pretty certain those 2 work on VS4M :)
| @@ -11,11 +11,23 @@ ms.topic: conceptual | |||
|
|
|||
| The *NuGet Client SDK* refers to a group of NuGet packages: | |||
|
|
|||
| * [`NuGet.Protocol`](https://www.nuget.org/packages/NuGet.Protocol) - Used to interact with HTTP and file-based NuGet feeds | |||
| * [`NuGet.Packaging`](https://www.nuget.org/packages/NuGet.Packaging) - Used to interact with NuGet packages. `NuGet.Protocol` depends on this package | |||
| * [`NuGet.Indexing`](https://www.nuget.org/packages/NuGet.Indexing) - NuGet's indexing library for the Visual Studio client search functionality. | |||
There was a problem hiding this comment.
We have at least one person/partner, who I'm confident is not VS4M, using NuGet.Indexing: NuGet/Home#11388
Although given the version number they reported, it sounds like they're getting the package though Arcade/Maestro, not nuget.org. Anyway, if we want to effectively remove this package as part of the client SDK, then we should be aware that it will break some people who are using it.
|
Consider merging this soon so that #3178 makes it live. |
kartheekp-ms
deleted the
dev-kpms-update-nugetclientsdk-addmissingpackages
branch
Thank you for being aware of this PR. I was about to merge it so that the changes can go live before we publish the blog post. |
Fixes: https://github.com/NuGet/docs.microsoft.com-nuget/issues/3175
NuGet Client SDK docs docs do not list all the packages that are published by the NuGet team.
The list of packages that are currently published by the NuGet Client team can be found in the source code or at https://www.nuget.org/profiles/nuget. The list of packages in the source code will not match with the list of packages that have already been published by the NuGet account on nuget.org. This is because a few of the packages were either deprecated or published by the server team.
Credit to @zivkan for raising awareness about this internally.