Open 0x53A opened 7 years ago
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.
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:
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)
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.
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...
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
Apparently yes, because https://github.com/fsprojects/Paket/issues/2326#issuecomment-300847138 worked back then :)
ok then that is, syntax wise, a non-issue. Now it would just need to work .=)
This still doesn't work after latest prerelease changes..
1 - let the resolver try
2 - pinned
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.