Skip to content

Pinned dependency causes conflict #1520

Closed

Description

@isaacabraham

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

Activity

  1. inosik commented on Mar 16, 2016

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

  2. forki commented on Mar 16, 2016

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

  3. forki commented on Mar 16, 2016

    @forki
    Member

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

  4. forki commented on Mar 16, 2016

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

  5. added 2 commits that reference this issue on Mar 16, 2016
    355708f
    28d9b82
  6. forki commented on Mar 16, 2016

    @forki
    Member
  7. forki commented on Mar 16, 2016

    @forki
    Member

    please give it another try

  8. reopened this on Mar 16, 2016
  9. isaacabraham commented on Mar 16, 2016

    @isaacabraham
    ContributorAuthor

    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?

  10. forki commented on Mar 16, 2016

    @forki
    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)

  11. isaacabraham commented on Mar 16, 2016

    @isaacabraham
    ContributorAuthor

    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?

  12. forki commented on Mar 16, 2016

    @forki
    Member

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

  13. added 2 commits that reference this issue on Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions