Pinned dependency causes conflict #1520

Closed
isaacabraham opened this Issue Mar 15, 2016 · 10 comments

Projects

None yet

3 participants

@isaacabraham
Contributor

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...

@inosik
Contributor
inosik commented Mar 16, 2016

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.

@forki
Member
forki commented Mar 16, 2016

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

@forki forki added the bug label Mar 16, 2016
@forki
Member
forki commented Mar 16, 2016

I'm pretty sure this is a bug, but not sure where exactly yet

@forki
Member
forki commented Mar 16, 2016

@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.

@forki forki added a commit that referenced this issue Mar 16, 2016
@forki forki Force resolver to look into deeper levels - fixes #1520
Force resolver to look into deeper levels - fixes #1520
28d9b82
@forki
Member
forki commented Mar 16, 2016

I think 28d9b82#diff-781e85b03afcc7c6cedfbd46e3d3b607R430 solves it.

@forki forki added a commit that closed this issue Mar 16, 2016
@forki forki Force resolver to look into deeper levels - fixes #1520
Force resolver to look into deeper levels - fixes #1520
28d9b82
@forki forki closed this in 28d9b82 Mar 16, 2016
@forki
Member
forki commented Mar 16, 2016

please give it another try

@forki forki reopened this Mar 16, 2016
@forki forki closed this Mar 16, 2016
@isaacabraham
Contributor

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?

@forki
Member
forki commented Mar 16, 2016

Yes now you can try to change the strategy to min.
On Mar 16, 2016 11:20 AM, "Isaac Abraham" notifications@github.com 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
#1520 (comment)

@isaacabraham
Contributor

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".

  • A = 1.2.3
  • A depends on B >= 1.2.3
  • I don't want B to ever go >= 2.0

I guess this is more about the package author of A (not specifying deps version boundaries tightly enough) than paket though, right?

@forki
Member
forki commented Mar 16, 2016

yes that is something that can't be really expressed in nuget

@forki forki added a commit that referenced this issue Mar 17, 2016
@forki forki Revert #1520 de5303d
@forki forki added a commit that referenced this issue Mar 17, 2016
@forki forki Revert #1520 e58ca0b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment