Latest paket, I have a dependencies file which I have reduced to: -
source https://nuget.org/api/v2
nuget Microsoft.ApplicationInsights.WindowsServer = 1.2.3
This does not work, although (as far as I can see) it should.
Resolving packages for group Main:
- Microsoft.ApplicationInsights.WindowsServer is pinned to 1.2.3
- Microsoft.ApplicationInsights 1.2.3
- Microsoft.ApplicationInsights.DependencyCollector 2.0.0
- Microsoft.ApplicationInsights.PerfCounterCollector 2.0.0
- Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel 2.0.0
- Microsoft.Diagnostics.Tracing.EventSource.Redist 1.1.28
- Microsoft.ApplicationInsights.PerfCounterCollector 1.2.3
- Microsoft.ApplicationInsights.DependencyCollector 1.2.3
Paket failed with:
There was a version conflict during package resolution.
Resolved packages:
- Microsoft.ApplicationInsights 1.2.3
- Microsoft.ApplicationInsights.DependencyCollector 1.2.3
- Microsoft.ApplicationInsights.PerfCounterCollector 1.2.3
- Microsoft.ApplicationInsights.WindowsServer 1.2.3
- Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel 2.0.0
Could not resolve package Microsoft.ApplicationInsights:
- Microsoft.ApplicationInsights.DependencyCollector 2.0.0 requested: 2.0.0
- Microsoft.ApplicationInsights.PerfCounterCollector 1.2.3 requested: 1.2.3
- Microsoft.ApplicationInsights.WindowsServer 1.2.3 requested: 1.2.3
Please try to relax some conditions.
It seems to be pulling in version 2.0 dependencies for some reason...
According to nuget.org, Microsoft.ApplicationInsights.WindowsServer v1.2.3 requires = 1.2.3 of Microsoft.ApplicationInsights and >= 1.2.3 for it's other dependencies. That's why Paket tries to get v2.0.0 of Microsoft.ApplicationInsights.*.
You could use strategy: min, to emulate NuGet's behavior of downloading the oldest compatible version. This should get v1.2.3 of every package, which Microsoft.ApplicationInsights.WindowsServer depends on.
I believe strategy:min vs max should not result in conflict vs. non-conflict since it only changes order. I'll take a deeper look
I'm pretty sure this is a bug, but not sure where exactly yet
@mrinaldi
It has something to do with this optimization:
match !state with
| Resolution.Conflict(_,_,stillOpen,_,_)
when stillOpen |> Set.exists (fun r -> r = currentRequirement || r.Graph |> List.contains currentRequirement) |> not ->
forceBreak := true
| _ -> ()
If I comment this block out then it finds a resolution.
I think https://github.com/fsprojects/Paket/pull/1521/commits/28d9b82b226cb03d56fa7b2c42466dadedb27727#diff-781e85b03afcc7c6cedfbd46e3d3b607R430 solves it.
please give it another try
Yeah works now! Interestingly I still get up to 2.x for some of the transitive dependencies - is there a way to stop this aside from adding those manually into the .dependencies file?
Yes now you can try to change the strategy to min.
On Mar 16, 2016 11:20 AM, "Isaac Abraham" [email protected] wrote:
Yeah works now! Interestingly I still get up to 2.x for some of the
transitive dependencies - is there a way to stop this aside from adding
those manually into the .dependencies file?—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1520#issuecomment-197248984
Hmmm. Yes that works as well although not _quite_ what I'm thinking, which is more "don't go above 'major' version of transitive dependencies".
I guess this is more about the package author of A (not specifying deps version boundaries tightly enough) than paket though, right?
yes that is something that can't be really expressed in nuget