Nugetgallery: NuGet.Server should show unlisted packages in FindPackagesById()

Created on 26 May 2017  路  12Comments  路  Source: NuGet/NuGetGallery

The package Catel.Core 5.0.0-alpha0234 is unlisted.

However it is displayed in the FindPackagesById()?id='catel.core'&$skip=600 query, which is unexpected.

In NuGet.Server for example, unlisted packages are ignored for this particular query, whereas NuGet.org does seem to include unlisted packages. Interestingly, Search() and friends properly exclude unlisted packages from the result data.

NuGet.Server Bug ops grabs

All 12 comments

The default behavior to include unlisted packages seems by design: unlisted packages still must be able to restore.

However, an optimization can be done here, because restore should always provide the version parameter too!

The above call does not include a version number, and thus, we should hide unlisted packages by default when the parameter is missing, to avoid discovery of these unlisted packages.

This test seems faulty: https://github.com/NuGet/NuGetGallery/blob/master/tests/NuGetGallery.Facts/Services/FeedServiceFacts.cs#L719

I see no reason to return unlisted packages on v2 FindPackagesById when no version is explicitly provided. The whole point of unlisting packages is to hide them from search / make them no longer discoverable, and this API seems to violate that behavior/design.

This would break the client, unfortunately there is no doc listing all the scenarios but 3.0.0 originally took this approach on the client side and had to roll everything back.

The client uses FindPackagesById to discover all versions, listed and unlisted, and then it prioritizes listed packages first when resolving dependencies. 2.x would use either.

This is important for this scenario:
A (unlisted) -> B (unlisted) with no version range specified.

If only B 1.0.0 exists and it is unlisted it would currently get installed, but if FindPackagesById changes behavior then A would fail to install since B would be missing.

It may also be the case that if all packages unlisted then install-package is suppose to work still. Also, I think there is an issue on the client that install-package doesn't even check for unlisted when finding the latest version.

But FindPackagesById() also does not return a Listed property of some kind, so the consumer of the API has no clue if it is listed or unlisted in this case. Fine with either but I'd like to know about listed / unlisted :-)

Plus does that mean NuGet.Server is faulty then?

But FindPackagesById() also does not return a Listed property of some kind

The published date is used in some scenarios by the client to determine if the package is listed.

Plus does that mean NuGet.Server is faulty then?

I would say so. I don't think NuGet.Server supported unlisting in the past, it did an actual delete.

VSTS feeds were removing unlisted packages from FindPackagesById recently and it was determined that it was incorrect.

Ah well :-) Will see if we can work around it.
Have a good weekend Justin!

To summarize things: the conclusion is that NuGet.Server doesn't should unlisted packages in FindPackagesById() and this is a bug?

Sounds like it, yes.

Thanks for the insights, @emgarten!
I agree package deprecation improvements could alleviate some of these issues.

Besides the NuGet.Server bug, I think the design choice for FindPackagesById should be documented too as it is not obvious looking at the code why some decisions were made.

Two action items here:

In the 2.x release of NuGet.Server, unlisted packages should be included in the FindPackagesById() output and the published date should be set to 1900. The listed property is not observed by NuGet client.

In the 3.x release of NuGet.Server, unlisted packages are already shown in the FindPackagesById() output, but the published date is not set to 1900 as with 2.x. This also needs to be fixed.

Was this page helpful?
0 / 5 - 0 ratings