NuGetV2-OData: retrieve versions in descending order #2008
Conversation
Some feeds have broken paging behavior. Getting only newer versions seems less of an issue than getting only older versions.
|
Verified against Artifactory. |
|
@forki have we had issues with other feeds (e.g. proget) in the past where this change could potentially cause problems? (If so, I'd expect NuGet Package Explorer to not work with them either) |
|
I never tried that. We can try it and if things break then we restrict this change to artifactory |
|
Does Paket already understand what server it is talking to? |
|
We only know the url Am 09.11.2016 09:02 schrieb "Christoph Ruegg" [email protected]:
|
|
If we ever need it (which I hope not), it actually tells so in the HTTP header: Technically we could leverage this to skip the v3 trials there (which it does not support), but let's not complicate things unnecessarily... |
|
So, can we give it a spin? :) |
|
yes please try it out |
|
Thanks, v3.27 works well for me. Suddenly commands like I don't have any other V2-only third-party feeds I can test against to verify myself unfortunately. |
|
@forki @cdrnet how shall we fix server-specific issues with OData? Optional source brand configWe could allow users to optionally specify their source brand in the paket.dependencies: Source brand probingBefore querying the feed, a dummy query is sent in order to catch up a trace of the source brand in the response. Then, when the source brand has been identified, specific fixes can be used at the right place. Option 1 sounds better to me as we do not add yet another HTTP get before querying the feeds. It is also potentially a less buggy behavior. Users that do not actively specify their source brand will not be impacted. |
|
tbh I'm fine with URL guessing. |
|
You mean trying to determine the brand by parsing the URL string specified as source? |
|
yes. we do that already for nuget.org and myget and things like that |
|
That would work fine for public servers where the domain name reflects for sure the server type, but for Intranet private servers it is not true at 100%
|
Related to fsprojects#2008 which was reverted in fsprojects#2018 because it affected non-artifactory servers negatively (in an unknonwn way). This change adds an alternative variant of tryGetAllVersions to fetch the versions in descending order (by publish date) instead of modifying the original one. GetVersions chooses to use the alternative variant in case the source uri contains the string "artifactory". This is a very unreliable way of discovering a server to be an artifactory one, but is in line with the existing rules and should prevent affecting non-artifactory servers. Ideally the decision should be more controllable than url matching, e.g. by introducing the concept of source options.
Some of the NuGet servers have broken feed paging. This PR changes the order such that newer packages are returned first (Publish date, descending). In case of broken paging, getting only newer versions seems less of an issue than getting only older versions. This is in particular relevant when using the update command without explicitly specifying a version (which downgrades to older versions otherwise). With this change, the request is also closer to how the
NuGet Package Explorerqueries all versions of a package.