BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Announcing the NuGet 3 Roadmap

by Jonathan Allen on Apr 29, 2014 |

In a recent article, Jeff Handley outlined the roadmap for NuGet 3.x. From its humble beginnings as a way to distribute out-of-band ASP.NET MVC packages, NuGet is now considered to be a vital part of the .NET ecosystem and Visual Studio itself. The four primary areas covered in the roadmap are: Package Discovery, Package Trust/Incompatibility, API, and Package Installation/Build.

Package Discovery

In the area of package discovery the features are fairly straight forward.

  1. Context-sensitive enumeration and search
  2. Statistics and reports for package authors and consumers
  3. Editable package metadata
  4. Package discovery and sharing through social graphs

Package Trust / Incompatibility

Currently there is no concept of trust for packages. Developers search for what they think is the right package, but unless it is a widely popular package there is plenty of room for malfeasance. One cannot even reliably look at the author’s name, as often the package is published under an individual’s name rather than an organization. Or alternately, multiple people share the same key, creating a security risk.

To address this issue, NuGet plans to add support for organization and team accounts. These accounts, as well as individual accounts, can then be rated based on the owner’s reputation.

In terms of incompatibility, there are two aspects to consider. The first is normal incompatibilities between projects. This will be handled with a reporting system that should be able to inform developers about problems mixing two packages in the same project.

The other kind of incompatibility is legal. Though the vast majority of packages on NuGet are offered via an open source license, not all licenses are compatible with each other. So another feature is the ability to filter by license name.

API Changes

Currently NuGet packages are being offered via a single OData service. With NuGet 3 that service will be spilt into what are now being called “micro services”. The exact APIs are still being worked out but the plan is to break it down into the following conceptual services.

  1. Downloads (serving both package installs and restores)
  2. Metadata and Feeds (for enumerating packages and resolving dependencies)
  3. Search (getting context-sensitive package lists and search results)
  4. Metrics (reporting download statistics)
  5. Events (exposing a stream of activity on the gallery, which can be utilized by a variety of different consuming services)

Features coming along with the new services include:

The new client API will also provide some features for these areas:

  1. Traversing package metadata easily without downloading packages
  2. Downloading packages without having to first read their metadata
  3. Invoke the dependency resolver without installing packages
  4. Determine if a package is compatible with a project without actually trying to install it
  5. Support for Semantic Versioning 2.0
  6. Support for architecture, configuration, and toolset groups in packages
  7. New dependency resolver features for more complex graphs

Infrastructure Changes

As anyone who has tried to search NuGet can attest, NuGet is suffering from its popularity. TO remedy this they are rebuilding their backend to follow a eventually consistent model.

NuGet is an extremely read-heavy system, with millions of reads for every write. Yet today’s design uses a system where writes are relatively cheap and reads are very expensive. It’s time to invert that!

To achieve virtually free reads, we’re moving to an eventually consistent response model. When packages get uploaded, package ownership changes, or other data writes occur, we’ll write that data to our authoritative data store immediately (presently SQL). But requests for package metadata or downloads won’t query against that authoritative data store. Instead, they will read JSON-LD blobs that are computed by back-end services.

There is a cost to this for publishers. Jeff continues,

This means it might take a few minutes before a published package is available for discovery and download. But for that trade-off, we can scale out our read capacity in a practically limitless manner. And we can separately scale our Work Service to make sure it can keep up with the data ingress.

Package Installation / Build

The most significant change from a developer’s perspective is probably the package installation and build changes. Unfortunately we don’t have much in terms of details. There is just this list of feature points:

  1. Resolve references at build time for better retargeting and multi-targeting
  2. Treat direct installs differently from dependencies
  3. Global package installations
  4. NuGet packages as a natural part of build
  5. NuGet packages replace assemblies as the natural unit of reference

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT