New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pinned dependency causes conflict #1520

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

Comments

Projects
None yet
3 participants
@isaacabraham
Contributor

isaacabraham commented Mar 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Mar 16, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

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

Member

forki commented Mar 16, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

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

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 added a commit that referenced this issue Mar 16, 2016

@forki

This comment has been minimized.

Show comment
Hide comment
Member

forki commented Mar 16, 2016

@forki forki closed this in 28d9b82 Mar 16, 2016

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

please give it another try

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

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Mar 16, 2016

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?

Contributor

isaacabraham commented Mar 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

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)

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

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Mar 16, 2016

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?

Contributor

isaacabraham commented Mar 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Mar 16, 2016

Member

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

Member

forki commented Mar 16, 2016

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

forki added a commit that referenced this issue Mar 17, 2016

forki added a commit that referenced this issue Mar 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment