Home: NuGet install installing delisted package if it is highest version

[jascam]

Problem:

If the highest version of a package is delisted NuGet will still install this package without having the -version flag used.

Ex:

nuget list zarenner-test -source https://api.nuget.org/v3/index.json -allversions
Notice that only Version 1.0.0 is listed
nuget install zarenner-test -source https://api.nuget.org/v3/index.json
Notice that version 2.0.0 is installed

Note:
I have reproed this against both the V2 and V3 endpoints for NuGet 3.2, 3.3 and 3.4 RC. For NuGet 2.8 however install seems to be pulling down the 1.0.0 version

[jskeet]

I'm surprised this has stayed open for over a year. It's a major problem with the delisting functionality, IMO. I would expect a delisted version simply not to be returned by the server unless explicitly requested by a client.

[davidfowl]

@jskeet When nuget brings back lock files for PackageReference this would be more feasible. The problem is that there's no difference between restore and initial install. Always skipping unlisted packages would mean less determinism and less efficiently since nuget would always have to go online to fetch the right version.

[forki]

There were recent changes in server side that removed unlisted packages from the getpackageversions api. So the problem might be gone.

[jskeet]

@forki: It's certainly present on nuget.org today. That's how I winded up here to start with.

[forki]

Yes nuget.org shows unlisted packages. But apis have changed. I know because paket's Integration test suite went red and then we asked ;-)

[jskeet]

@davidfowl: I'm not sure what you mean (probably due to my ignorance of how nuget works). If the client knows the version it wants, I'd expect it to say so and be able to "see" the delisted version. If it's asking "What's the latest version" I would not expect it to see the delisted version.

My actual case: I screwed up tagging when I was trying to release Noda Time 2.1.0, and accidentally pushed a 2.2.0 package. I immediately delisted it, and thought that would be enough - but it's not. Now anyone installing Noda Time with just "nuget install NodaTime" ends up with the bogus 2.2.0. I've sent a request to have 2.2.0 removed, but at the moment it feels like delisting is fundamentally broken compared with what it's claiming:

Unlisting the package will prevent users from finding it by searching the gallery and it will prevent the dependency resolver from discovering the package. However, the package will still be available for download through NuGet Package Restore so that existing projects referencing the package don't become broken.

[jskeet]

@forki: Until nuget.org stops exposing unlisted package versions when they're not being explicitly requested, I don't think we can reasonably say that the problem is "gone".

[forki]

Until nuget.org stops exposing unlisted package versions when they're not being explicitly requested,

which API did you ask? what's the concrete URL?

[forki]

@jskeet another tip: you should cancel your request for package deletion if people have already installed it. That will result in even more trouble. ;-)

[davidfowl]

@davidfowl: I'm not sure what you mean (probably due to my ignorance of how nuget works). If the client knows the version it wants, I'd expect it to say so and be able to "see" the delisted version. If it's asking "What's the latest version" I would not expect it to see the delisted version.

That doesn't work for transitive dependencies. If another package depends on the de-listed version of noda time, it would require the nuget client to go online to get the "right" version, since the version listed in the dependency of the nuspec isn't enough to make a decision. e.g.

NodaTime 2.0.0 (delisted), NodeTime 3.0.0

Foo 1.0.0 -> NodaTime 2.0.0

Should nuget get 2.0.0 or 3.0.0? That's an extreme case but it's why the current restore process does what it does (ignores unlisted).

My actual case: I screwed up tagging when I was trying to release Noda Time 2.1.0, and accidentally pushed a 2.2.0 package. I immediately delisted it, and thought that would be enough - but it's not. Now anyone installing Noda Time with just "nuget install NodaTime" ends up with the bogus 2.2.0. I've sent a request to have 2.2.0 removed, but at the moment it feels like delisting is fundamentally broken compared with what it's claiming:

OK this I agree with. The nuget install command could have this logic, I think that's actually fine. The UI and the command line could respect the de-listing.

Better to just release a 2.3.0 😄 for now to solve all issues...

[jskeet]

@forki: I just used the nuget command line client (v4.1.0.2450).

But yes, I see what you mean about the deletion request. It sounds like I probably need to actually do a 2.3.0 release so that the most recent version is a valid, listed one.

TL;DR: If you ever accidentally push a package with the wrong version number, you're screwed and delisting doesn't help you in any significant way, even if you notice within seconds. I completely acknowledge that the original cause was my fault, but the effect is out of all proportion, IMO.

[jskeet]

@davidfowl: In the case where anything does already have the delisted version, I agree there are problems. But in the case where the delisted version isn't already being used, I'd expect nothing to ever see it. Maybe that's infeasible due to the way the conversations between client and server work...

[jskeet]

Actually, I think I can probably just relist 2.2.0 and then skip to 2.3.0 for new work. (Nothing had happened on the master branch when it was accidentally used...)

[forki]

ok I take everything back. Seems https://api.nuget.org/v3-flatcontainer/nodatime/index.json?semVerLevel=2.0.0 is showing unlisted again. So the change was probably rolled back.

{
  "versions": [
    "0.1.0",
    "0.9.0",
    "1.0.0-beta1",
    "1.0.0-beta2",
    "1.0.0-rc1",
    "1.0.0",
    "1.0.1",
    "1.1.0-dev",
    "1.1.0-dev-2013-31-01",
    "1.1.0-rc1",
    "1.1.0",
    "1.1.1",
    "1.2.0-rc1",
    "1.2.0-rc2",
    "1.2.0",
    "1.3.0-beta1",
    "1.3.0-dev-20140515",
    "1.3.0-dev-20140518",
    "1.3.0",
    "1.3.1",
    "1.3.2",
    "1.3.3",
    "1.3.4",
    "1.4.0-beta1",
    "1.4.0",
    "2.0.0-alpha-20160523",
    "2.0.0-alpha20140807",
    "2.0.0-alpha20140808",
    "2.0.0-alpha20150718",
    "2.0.0-alpha20150728",
    "2.0.0-alpha20160523",
    "2.0.0-alpha20160707",
    "2.0.0-alpha20160729",
    "2.0.0-beta20170123",
    "2.0.0-rc1",
    "2.0.0-rc3",
    "2.0.0",
    "2.0.1",
    "2.0.2",
    "2.0.3",
    "2.1.0-beta01",
    "2.1.0",
    "2.2.0"
  ]
}

It's still clear that nuget.exe should not install it since the getpackagedetails api clearly shows it as unlisted. fwiw Paket doesn't install it (only if it's explicitly required because of other deps).

[jainaashish]

dupe of https://github.com/NuGet/Home/issues/5069

[forki]

@jainaashish this one here is older and with customer subscriptions. Just saying...

[jainaashish]

@forki both issues have some customer subscriptions, but 5069 has more details and clear repro steps which is why I kept that open and also linked that bug here so that anyone watching this one, can go there.