Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
ProGet: Handling of deprecated NuGet packages
-
Hi there!
It seems like ProGet currently doesn't handle NuGet's package deprecation feature at all. I saw a post from someone asking about deprecating one's own packages in ProGet, but I'm wondering about the handling of deprecated external packages. Would it be possible to have the follwing features in ProGet:
-
Display deprecation info in Proget
At the very minimum, the package’s deprecated info should be shown at the package’s info page. This includes any additional info that the package’s maintainer provides, e.g. a custom message and a link to an alternate package, if provided. Compare the info shown for Microsoft.AspNetCore in ProGet and on nuget.org:
Optionally, the info could also be shown in the search results (see nuget.org as an example):
-
The deprecation info should be visible in Visual Studio / dotnet.exe
Visual Studio warns users if they use deprecated packages when connecting to api.nuget.org:
However, when connecting to ProGet, no warning is shown:
My guess is that this is another part of the nuget API, that is yet to be implemented by ProGet (like the vulnerability info, see PG-2359). -
SCA Reporting should report deprecated packages
Just like warnings about vulnerable packages or packages with unwanted licenses, SCA reports should show a warning when deprecated packages / package versions are used by a release. -
Handle unlisted packages like deprecated packages
ProGet allows for packages to be unlisted by user. In those cases, it would be nice if the features mentioned above could be applied to unlisted packages as well (display warning in Visual Studio, issues in SCA reports).
I'm aware that this is probably not a trivial request, because NuGet packages can become deprecated after they have been cached by ProGet, in which case ProGet probably won't update the package's metadata. However, there are already some maintenance tasks running regularly within ProGet (like PackageAnalyzer), so maybe it would be possible to regularly check if if the metadata of cached packages is still the same? Or maybe such an update-task actually already exists?
-
-
Hi @sebastian ,
In ProGet 2023, deprecation information will be shown on the package page and through API:
The information is passed through connectors and can be set on local packages on the package status page:
They should also show up as issues in SCA reports.
However, as you noticed, it is server-side metadata (like listing status, download count, package owners, etc.), and we don't have any mechanism to "sync" server-side metadata from connectors at this time. That may come in ProGet 2024 but it's not trivial to generalize.
However, you could probably write a script that uses the new Common Package API to easily retrieve packages from a feed, check their status on nuget.org, and update deprecated info.
Best,
Steve
-
Hi @stevedennis
Thanks for your reply. I tried to get the deprecation info into ProGet to see how things look like in VS and in the SCA reports, so I deleted the package from my example above from the cache using the "Delete Cached Package" button. Once the package was deleted, I indeed saw the deprecation info on the package's info page:
However, once I downloaded the package from ProGet, it seems the deprecation info was lost:
Same goes for the package from your example (which had not been previously downloaded and cached on our ProGet installation): Once I downloaded the package, the deprecation info is gone. Does that mean that ProGet does not copy NuGet's deprecation info when downloading a package, even when that status is already set at the time of the download? Is this a bug or intended?
-
Hi @sebastian ,
This behavior is "intentional" but not ideal; we simply add the package file to the feed but don't set any server-side metadata properties.
This seems like something we should change, so I logged PG-2426 to address this; perhaps we'll get it in the next maintenance release. It seems relatively simple, but I didn't look too deeply
Best,
Steve
-
Hi @stevedennis
Some additional info: I deleted the package from ProGet's cache again to test the SCA reporting. However, even though the package's info page now shows the deprecation info correctly, I don't see any warning in my SCA report. I then downloaded the package again and wanted to set the status manually to see if that makes any difference. However, I'm somehow too blind to find a "set status" option. I know that when a package has a vulnerability, I can set its status by clicking on a link within the vulnerability message, but I simply can't find such a link/button for a package that doesn't have any vulnerabilities.
One more thing: you mentioned writing our own "package updater" script using ProGet's Common Package API. Is there a way to list all packages that are cached by ProGet? Because those are the only ones I'd want to check for new metadata. Checking every single package on nuget.org and comparing its data to the data provided by ProGet (or vice versa) would be unfeasible.
-
@sebastian it looks liike the "set package status" only appears for Local Packages...
When testing this, I noticed that there was a bug with the release analyzer; basically it's a constraint that wasn't properly added. We'll fix this via PG-2428, but you can just run this script - and deprecated packages should show up. At least on my machine :)
ALTER TABLE [ProjectReleaseIssues23] DROP CONSTRAINT [CK__ProjectReleaseIssues23__IssueType_Code] ALTER TABLE [ProjectReleaseIssues23] -- [V]ulerability, [M]issing Package, [O]utdated Package, [L]icensing Issue, [D]eprecated ADD CONSTRAINT [CK__ProjectReleaseIssues23__IssueType_Code] CHECK ([IssueType_Code] IN ('V', 'M', 'O', 'L', 'D'))Is there a way to list all packages that are cached by ProGet?
That API will allow you to list all packages in a feed; you'd basically want to query NuGet for each of those packages.
-
@stevedennis
Just wanted to let you know that I tested this with 2023.13 and both issues (PG-2426 and PG-2428) do indeed seem to be fixed with this version. However, it took some time for the package's page to show that the package has been deprecated after I downloaded it. I guess the package analyzer had to run to correctly show the package's state?What's left is some kind of periodic check for updates on a packages' metadata after it has been downloaded. This would be really useful (doesn't have to be daily, once a week would suffice).
BTW: We are currently looking into the API approach that you suggested and one question came up: Is there a way to add custom scheduled jobs to ProGet (like the UpdateChecker or PackageAnalyzer tasks)? If not, could something like that be added via the Inedo.SDK in the future? I know we can just trigger it with a generic job scheduler, but it would be nice to have all ProGet-related maintenance jobs in one place.
Cheers,
Sebastian
-
Hi @sebastian
There is no plan to add user-configurable scheduled job capabilities to ProGet, and it's unlikely we would consider that since they are really hard to support. We do have our Otter product that's designed for that
However, in ProGet 2022, we considered a periodic "check" for packages in a feed against the source; the use case was "is a newer patch version available" - and if so, then an issue would be raised about using an out-of-date package. We obviously didn't implement that.
But it seems we could take a similar approach and then also check for unlisting/deprecation as well. This might be something that comes up in our ProGet 2024 planning.
But in either case, it still involves lots and lots of web calls to check each package against the source - so I would start with a a script and see what you find out.
Thanks,
Alana
