Pulp

# NuGet Packages

This would manage .nupkg files, which are renamed ZIP files with a special \<id\>.nuspec file in the root.

The .nuspec is documented with an xsd on GitHub: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Packaging/compiler/resources/nuspec.xsd  

Uniqueness is determined as a combination of id and version from the spec, with added digest.  

Core attributes are id and version. They are both strings and are required to discover NuGet packages.

Additional simple optional attributes that could be added are;  

\- authors : string  

\- copyright : string  

\- description : string  

\- language : string : default en-US  

\- owners : string  

\- summary : string  

\- tags : string  

\- title : string

Clients that access NuGet packages are; nuget (Both by itself as well as a package-manager plugin for Visual Studio), the dotnet CLI tool, the Chocolatey tool, and just plain curl works too.

For content discovery, a core index JSON lists available services on the registry (https://registry.example/v3/index.json)  

The Catalog/3.0.0 service provides json blobs for full content listing, split into several "pages" of JSON. (https://docs.microsoft.com/en-us/nuget/guides/api/query-for-all-published-packages)  

Additionally, the PackageBaseAddress/3.0.0 service provides the base address for generating a download URL from {@id}/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.{LOWER_VERSION}.nupkg (https://docs.microsoft.com/en-us/nuget/api/package-base-address-resource)

The JSON blobs contain identical metadata to the nuspec XML, just in JSON format.

To make the client happy about finding packages in large registries, the SearchQueryService would probably have to be implemented as well - as a live API. (https://docs.microsoft.com/en-us/nuget/api/search-query-service-resource)