Paket: [5.0.0-beta008, regression] resolving fails with funny version numbers

[0x53A]

1 - let the resolver try

source https://www.nuget.org/api/v2

framework: net461

nuget NETStandard.Library prerelease
nuget NETStandard.Library.NETFramework prerelease

Paket version 5.0.0-beta008
Resolving packages for group Main:
 - NETStandard.Library 2.0.0-preview1-25301-01
 - NETStandard.Library.NETFramework 2.0.0-preview1-25305-02
 - Microsoft.NETCore.Platforms 2.0.0-preview1-25305-02
 - NETStandard.Library 1.6.1
 - NETStandard.Library 1.6.1-preview1-24530-04
 - NETStandard.Library 1.6.0
 - NETStandard.Library 1.5.0-rc2-24027
Performance:
 - Resolver: 1 second (1 runs)
    - Runtime: 109 milliseconds
    - Runtime Paket 4 (estimated ~500ms respose*): 7 seconds
      * See http://stats.pingdom.com/aqicaf2upspo/1265300 for average response times.
    - Blocked (retrieving package versions): 842 milliseconds (8 times)
    - Blocked (retrieving package details): 207 milliseconds (7 times)
 - Average Request Time: 382 milliseconds
 - Number of Requests: 4
 - Runtime: 1 second
Paket failed with:
        There was a version conflict during package resolution.
  Resolved packages:
   - NETStandard.Library 1.5.0-rc2-24027
  Conflict detected:
   - Dependencies file requested package NETStandard.Library.NETFramework: >= 0
   - Available versions:
     - (2.0.0-preview1-25305-02, [https://www.nuget.org/api/v2])

  Please try to relax some conditions or resolve the conflict manually (see http://fsprojects.github.io/Paket/nuget-dependencies.html#Use-exactly-this-version-constraint).

2 - pinned

source https://www.nuget.org/api/v2

framework: net461

nuget NETStandard.Library == 2.0.0-preview1-25301-01
nuget NETStandard.Library.NETFramework == 2.0.0-preview1-25305-02

 Paket version 5.0.0-beta008
Resolving packages for group Main:
 - NETStandard.Library.NETFramework 2.0.0-preview1-25305-02
 - NETStandard.Library 2.0.0-preview1-25301-01
 - Microsoft.NETCore.Platforms 2.0.0-preview1-25305-02
Performance:
 - Resolver: 796 milliseconds (1 runs)
    - Runtime: 132 milliseconds
    - Runtime Paket 4 (estimated ~500ms respose*): 2 seconds
      * See http://stats.pingdom.com/aqicaf2upspo/1265300 for average response times.
    - Blocked (retrieving package details): 249 milliseconds (3 times)
    - Blocked (retrieving package versions): 414 milliseconds (1 times)
 - Average Request Time: 558 milliseconds
 - Number of Requests: 3
 - Runtime: 1 second
Paket failed with:
        There was a version conflict during package resolution.
  Resolved packages:
   - Microsoft.NETCore.Platforms 2.0.0-preview1-25305-02
   - NETStandard.Library 2.0.0-preview1-25301-01
   - NETStandard.Library.NETFramework 2.0.0-preview1-25305-02
  Conflict detected:
   - Dependencies file requested package NETStandard.Library: == 2.0.0-preview1-25301-01 (preview)
   - NETStandard.Library.NETFramework 2.0.0-preview1-25305-02 requested package NETStandard.Library: >= 2.0.0-preview1-25301-01

Note that the second case is extra bad - not only does the resolver fail, it also ignores the _exactly this_ operator, which should override any conflicts.

---

__Note that this is a regression, 4.8.6 can resolve it in both cases.__

[matthid]

Might be related https://github.com/fsprojects/Paket/issues/2326 (Might have the same root cause).

I already thought we have some problems with allowing prereleases, I guess this is either the proof for it or a completely separate issue...

Either way both should be added to the unit test suite.

[matthid]

I think here we need to decide in which situations we want to allow prereleases in transitive dependencies and then implement it.

My suggestion is:

• If a package is marked with "prerelease" we accept prerelease in all transitive dependencies
• For transitive dependencies stable packages need to be preferred if they match the version range (to prevent the situation where somewhere else in the deps-tree different pre-releases are introduced which are not wanted by the user)
• Once we have a stable transitive dependency we do no longer accept pre-releases for sub dependencies.

I cannot really say how hard this is to implement. But an implementation should come with quite some unit tests for each condition.

Note that the only reason why paket 4 probably works is that paket 4 has a bug which allows "inconsistent" resolutions (from the paket point of view)

[0x53A]

There also needs to be a way to allow prerelease dependencies when pinning a package to a non-prerelease version.

For example:

# depends on NETStandard.Library >= 1.6 (non-prerelease)
nuget ns16lib 1.0
# depends on NETStandard.Library prerelease
nuget NETStandard.Library.NETFramework prerelease

Currently this will fail, because ns16lib depends on release, NETStandard.Library.NETFramework depends on prerelease.

[matthid]

Yep, it's kind of hard as it depends how we process through the search-tree. We probably need to start with prerelease deps. Otherwise we might have already "excluded/traversed" prereleases which we would have required...

[0x53A]

Can I specify both a pinned version and prerelease?
e.g.

# pin to 1.0, but allow prerelease dependencies
nuget ns16lib 1.0 prerelease
# depends on NETStandard.Library prerelease
nuget NETStandard.Library.NETFramework prerelease

[matthid]

Apparently yes, because https://github.com/fsprojects/Paket/issues/2326#issuecomment-300847138 worked back then :)

[0x53A]

ok then that is, syntax wise, a non-issue. Now it would just need to work .=)

[matthid]

This still doesn't work after latest prerelease changes..