Closed MisinformedDNA closed 5 years ago
@MisinformedDNA - the question is, a preferered method for what? Can you tell us a little more about what you are trying to do?
cc: @joelverhagen
I'm trying download a list of packages and details of those packages to do some analysis.
have you seen these docs - https://docs.microsoft.com/en-us/nuget/guides/api/query-for-all-published-packages ?
Yes, that's what pointed me to the example cited above. It's just weird that there is a NuGet package for NuGet commands, but it isn't actually used.
The NuGet.Protocol
package is very much geared for the NuGet client scenarios (nuget.exe, dotnet command line, etc). As a result, this package doesn't implement protocols that aren't used by client scenarios. The catalog resource is one such protocol, so instead I recommend you use the NuGet.Protocol.Catalog
SDK.
I agree this is weird. The NuGet.Protocol
and NuGet.Protocol.Catalog
libraries aren't well integrated as the former is maintained by the NuGet client team and the latter by the NuGet server team. We've had discussions on how to merge our libraries together, but this is surprisingly tricky to do well.
Just to add a bit to what @loic-sharma said.
The word "commands" in NuGet.Commands
refers to the high level operations performed nuget.exe and .NET CLI (the NuGet specific commands, that is) -- like the logic right beneath nuget.exe {command}
. These certainly can be used by people to hack together custom ideas but in general the design of NuGet.Commands and NuGet.Protocol is almost solely for the immediate goals of the official NuGet clients. To help you understand what I mean, some patterns in the NuGet.Protocol and NuGet.Commands libraries are:
Only provide .NET APIs for endpoints necessary for these official commands (as mentioned by @loic-sharma). So the catalog resource is not covered here. Also, there is no .NET to get the .nuspec from flat container, AFAIK.
Abstract away different types of package sources. For example, these high-level commands should work just fine whether you are using a V2, V3, or file-based source (which there are some variants of).
These aren't hard rules, just patterns I've noticed during my time on NuGet team 😄.
Because of point 1, doing a "full scan" of nuget.org isn't possible with NuGet.Commands. There is no scenario where the official client needs to do this today (well, there is nuget.exe list
but that's a strange case for other reasons and isn't 1:1 with what the catalog offers).
Because of point 2, the code in these libraries is more complex or abstract than what is really necessary if you just want to hit nuget.org's HTTP endpoints.
I'm not saying there couldn't be a common set of shared libraries (in fact, that would be awesome!) but there just hasn't been the time or discussions necessary to get this done in such a way that we a) enable all the flexibility that nuget.org itself needs and what community members like you need and b) don't completely break existing users of these packages with API changes.
I think in the short term, the server team (who maintains nuget.org) can work on pulling together all of the .NET APIs we've internally implemented so people like you can start hacking! Maybe we can even put them on nuget.org (what a novel idea!?!?)
Some other code that fits in the same bucket as NuGet.Protocol.Catalog:
Code for the package metadata (a.k.a. registrations) resource: https://github.com/NuGet/NuGet.Services.Metadata/tree/dev/src/NuGet.Services.AzureSearch/Registration
Models for the search resource: https://github.com/NuGet/NuGet.Services.Metadata/tree/dev/src/NuGet.Services.AzureSearch/SearchService/Models
Another copy of catalog APIs 😓: https://github.com/NuGet/NuGet.Services.Metadata/tree/dev/src/NuGet.Protocol.Catalog
Cool, I was using the NuGet.Protocol.Catalog code in the sample, because I consistently missed the documentation that pointed to the myget resource. :)
TL;DR - yes, the nuget libraries are worth using.
I went through the CatalogReaderExample and was surprised that the only NuGet package being used was
NuGet.Protocol
. Everything else was just makingHttpClient
calls. IsHttpClient
the preferred method?