Incorrect NuGet version detection (V2 vs V3)

Description

We are using a private NuGet source repo (feedz.io) which does not include /v3 in the URL for the source. When using Paket, it detects it as a V2 repo even though it should be V3.

This appears to be due to the logic here: https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Versioning/PackageSources.fs#L148-L151

Note that the code only assumes v3 if the URL has /v3 or is GitHub and ends in index.json. In this case, Feedz.io uses the index.json (which that URL includes the version info) file, but does not use /v3 in their API end points.

This also appears to be the same issue hit by other Paket users, whom have attempted to address (see https://github.com/fsprojects/Paket/pull/3806 and https://github.com/fsprojects/Paket/issues/3575).

Repro steps

Repository at https://github.com/ReedCopsey/paket_bug demonstrates this. Using dotnet paket install gives many errors.

Expected behavior

Paket would resolve this as V3 (somehow) and function properly.

Actual behavior

Significant errors.

Known workarounds

None.

[tebeco]

i’m not sure doing “url detect” is a good thing to be honest

https://foo-v3-bar/v2/index.json
https://foo-v3-bar/v2/
https://foo-v2-bar/v3/index.json
https://foobar/buzz

they could all be v2 or v3 feed, it’s just a webserver replying to requests I’ve lost hours at work because we spotted paket and artifactory speaking v2 => FindPackageById() with v3 + index.json urls …

An alternative idea would be to allow user to be enforce it like this : source https://foo/bar protocolVersion:3

protocolVersion specified ?

• use it
• not compliant => just throw “that source does not seems to be v3”

protocolVersion not specified ?

• attempt detection, but not too much
• failfast / throw / indicate that they have to specify protocolVersion on that source

also … I would even go further v2 is kinda deprecated => no version specified ? assume v3 and just throw if not compliant, and ask user to be explictly using v2 it means you can just remove all detection code from paket. Probably near to 0 detection feature bug but yeah … breaking change … still better than URL detection / parsing / contains(v3) or endwith(‘index.json’)

If the idea of paket and lockfile are to have a “clear state” in the lockfile, it means that it should be explicitly written down. As the Protocol Version is part of the source, well that would make sense to write it down in paket.dependencies and then in paket.lock And then the “detection attempt” would not make sense since it’s part of the state, and then predictible

[tebeco]

I’ll try to fix that Url not sure why it was not originally in the unit test to be fair if it was a known “magic one”

do you have idea about other one that could have been forgotten ?