Marking packages as deprecated

benjamin.soddy_9591

How can I mark packages as deprecated? Package deprecations are a defined component of the NuGet Server API.

I am currently managing projects using the dotnet CLI's project package commands. With this I am able to create deprecation reports for projects with dependencies on deprecated nuget.org packages. However I am unable to do so with any packages derived from a ProGet server source.

atripp

Hi @benjamin-soddy_9591 ,

ProGet does not have support for package deprecations at this time, and we haven't had anyone ask about them until now :)

It could be very tricky to implement, because once a package version is pulled or cached to ProGet, there is no "synchronization" of "server-only" metadata. The reason is, packages versions are supposed to be immutable, and metadata self-contained.

The "unlisted" flag is similar. If a NuGet pulled/cached package becomes unlisted, then ProGet won't "know" about that, and therefore can't inform the client.

There doesn't seem to be any value in depreciating a first-party package (i.e. a library you create), as even the largest organizations should have communication channels for library authors and framework teams. Plus, they can monitor usage, and reach out directly to teams.

However, but I can see why you'd want to know which third-party packages are deprecated... but so far as we saw, very few package authors deprecate their packages. There seem to be better tools (vulnerability scans) to see if there are problem libraries.

So, if you could share some more specifics about what you're doing, why deprecation is helpful (with specific packages), etc., metadata would really help us understand the value in such a feature.

benjamin.soddy_9591

I am extraordinarily apologetic for resurrecting this, but it seemed more correct than creating a new, duplicate topic.

My organization has been and is in the process of making a large number of acquisitions. These companies have their own disparate systems and processes. However, a unifying aspect of the .NET companies is their use of the NuGet API and .NET SDK. Using these channels for deprecations and vulnerabilities via dotnet list package --vulnerable and dotnet list package --outdated is highly desirable. In no uncertain terms, dependencies distributed and shared by these teams are have few differences when compared with dependencies from NuGet.org. In fact, some dependencies shared amongst these teams are distributed via NuGet.org as public packages.

It is far more direct to use established standards which work with NuGet.org feeds, than to add an additional burden of knowledge. At the moment, the only recourse is to create a NuGet.org organization and change our distribution model.

stevedennis

Hi @benjamin-soddy_9591,

No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.

We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.

The dotnet list package --vulnerable is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.

The same is true with dotnet list package --outdated -- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.

There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies

Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.

Cheers,
Steve