RFC: Package Vision / Package Lenses

[jzabroski]

This is a Architecture Design RFC. Maybe this feature exists and I don't know how to use fuget.org properly, or missed some things when looking through the code.

I propose Package Vision, a marketing brand for a collection of services generalizing ApiDiff class, whereby we can write analysis tools on the PackageData class. Each package analyzer will be called a Package Lens in the UI, as it would provide a unique view at the package assets.

Potentially, Package Lenses could be uploaded to fuget.org as "sidecar" packages and tagged with which nuget.org packages they're intended to analyze. For example, if you've upgraded from one version of a library to another, and want to share your upgrades, you could use the output of the ApiDiff tool to describe how to resolve breaking changes you've found. In this sense, lenses are a collaborative tool with full access to the packages symbolic dependencies.

The key idea is that while the API Diff tool is great, I often want to answer specific questions, such as:

• What was the last version of Autofac that can support net461?

  • The answer to this is https://www.nuget.org/packages/Autofac/4.9.4 because it supports net45 TFM, which will also therefore support net461 via binding redirects.

• What was the last version of Autofac.Extensions.DependencyInjection that supported Autofac 4.9.4?

  • Alternatively, what was the last version of this package that supported Autofac MajorVersion=4)

• Are the transitive dependencies kept up-to-date?

  • Calculate the time the package updated its dependencies to when the dependency was published on Nuget.
  • Report on which projects outside Microsoft's "out-of-box" (OOB) packages are the most actively maintained
  • Detrend all other packages against the package universe

• Executable metadata suggesting its a Tool

  • Is the package a .NET Core CLI Tool?
  • If the package targets legacy .NET Framework TFMs, does the package contain an .exe?
  • Does the package contain any msbuild *.targets files and *.props?

• Moving the ApiDiff logic to use PublicApiGenerator project and allowing people to write scripts against the ApiDiff endpoint as if they were transparent remote procedure calls

• Is it safe to reference a netstandard2.0 TFM nuget package in an application with any of the followingTargetFrameworks: netstandard2.1;netcoreapp3.0;netcoreapp3.1?

• Is the package targeting netstandard2.0 TFM and netstandard2.1? If so, is it transitively pulling in dependencies that can be instead pulled in via FrameworkReference introduced in .NET Core 3.0?

• For each dll in the Nuget package, what does the PE Header say the AssemblyVersionAttribute is ?

  • If the AssemblyVersionAttribute value doesn't match the Nuget Package Version, a message should appear stating: "⚠️ Warning: The author of this package is using different versioning policies for the AssemblyVersionAttribute in the dll and for the version in the nupkg ⚠️"
  • For example, see https://www.fuget.org/packages/System.ComponentModel.Annotations/4.7.0 - I love the fact I can mouse over the Assembly and see that the AssemblyVersionAttribute is actually 4.3.1 - this feature helped me solve a problem over Christmas Break 2019 that had been vexxing me for >2 years

[praeclarum]

These are all great ideas, thank you. I have really wanted to integrate the diff results with more of the UI and these are interesting ways to do that.

I'm a little unclear about the sidecar feature, but will re-read and think about it.

[jzabroski]

The basic idea is that nuget.com already supports uploading analyzers as packages. Pretty much the only special types nuget.com supports today are Tools (.NET CLI Tools) and Symbol Packages (snupkg format for debugging and source linking).

As an initial prototype, all you need to do is check if the package has a tag "packagelens=PackageName" and you'll know its meant to be a lens for a particular package. If it gains traction and popularity, it can then become a formal nuget.com standard. No other community in other languages has something like this. Smalltalk is probably the closest.