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

Paket updates dependency in unrelated group #3259

Closed
bacar opened this Issue Jun 18, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@bacar

bacar commented Jun 18, 2018

Description

When I run commands to add or remove packages to a specific group, unrelated packages in the Main group in the paket.lock file are impacted.

For example I run paket add -g Foo Newtonsoft.Json

Newtonsoft.Json has no dependencies (for framework: net45) and nothing I've referenced elsewhere depends on newtonsoft. So this is a completely isolated change in a completely separate group, Foo. And yet making this change bumps the version of System.Collections.Immutable in the Main group from 1.4 to 1.5 in the repro case below (tested with 5.172.4)

Is this expected? It seems extremely surprising. I do understand that paket needs to work out the full dependency graph to solve the constraints, but I very much thought that the whole point of the paket.lock file was to be able to have tight control over what I change and when, and that it would prefer to keep things unchanged if it can (unless of course I am actually trying to paket update specific dependencies/everything). It seems very odd that it is updating a package that is not a dependency or dependent of the package I'm adding. It means I can't add/remove individual packages in isolation without potentially making completely unexpected and irrelevant changes to other components. Apologies if I'm fundamentally misunderstanding something about how paket is meant to work.

I could run with --keep-patch but this doesn't fully resolve the issue - I have the same problem whilst running paket remove -g Foo ElasticSearch.Net (which doesn't have a keep-patch option). I also get the same problem whilst running a paket update on a specific dependency (e.g. say I have Newtonsoft in group Foo, at version 9.0.1, and I want to paket update it to 11.0.2, then I have to omit --keep-patch, but then System.Collections.Immutable is affected).

I see the same behaviour if I try to add the dependency to the main group too with paket add Newtonsoft.Json. Again this seems surprising to me, but I've focused on the 'separate group' example as I think that ought to give me more isolation.

Note that I could not repro this with a tighter set of dependencies e.g. just System.Reflection.Metadata (which depends on System.Collection.Immutable) instead of RazorEngine.Roslyn so in other cases the behaviour is as I expect.

Repro steps

Create paket.dependencies

framework: net45

source https://www.nuget.org/api/v2

nuget RazorEngine.Roslyn
nuget Microsoft.CodeAnalysis 1.3.2
nuget System.Collections.Immutable >= 1.3.1

group Foo
  framework: net45

  source https://www.nuget.org/api/v2

  nuget ElasticSearch.Net 5.6

Create paket.lock:

RESTRICTION: == net45
NUGET
  remote: https://www.nuget.org/api/v2
    Microsoft.AspNetCore.Razor (2.1)
    Microsoft.CodeAnalysis (1.3.2)
      Microsoft.CodeAnalysis.CSharp.Workspaces (1.3.2)
      Microsoft.CodeAnalysis.VisualBasic.Workspaces (1.3.2)
    Microsoft.CodeAnalysis.Analyzers (2.6.1)
    Microsoft.CodeAnalysis.Common (1.3.2)
      Microsoft.CodeAnalysis.Analyzers (>= 1.1)
      System.Collections.Immutable (>= 1.1.37)
      System.Reflection.Metadata (>= 1.2)
    Microsoft.CodeAnalysis.CSharp (1.3.2)
      Microsoft.CodeAnalysis.Common (1.3.2)
    Microsoft.CodeAnalysis.CSharp.Workspaces (1.3.2)
      Microsoft.CodeAnalysis.CSharp (1.3.2)
      Microsoft.CodeAnalysis.Workspaces.Common (1.3.2)
    Microsoft.CodeAnalysis.VisualBasic (1.3.2)
      Microsoft.CodeAnalysis.Common (>= 1.3.2)
    Microsoft.CodeAnalysis.VisualBasic.Workspaces (1.3.2)
      Microsoft.CodeAnalysis.VisualBasic (1.3.2)
      Microsoft.CodeAnalysis.Workspaces.Common (1.3.2)
    Microsoft.CodeAnalysis.Workspaces.Common (1.3.2)
      Microsoft.CodeAnalysis.Common (1.3.2)
      Microsoft.Composition (>= 1.0.27)
    Microsoft.Composition (1.0.31)
      System.Composition (>= 1.0.31)
    RazorEngine (4.5.0-rc1)
      Microsoft.AspNetCore.Razor (>= 1.0)
    RazorEngine.Roslyn (4.1.1-rc1)
      Microsoft.AspNetCore.Razor (>= 1.0)
      Microsoft.CodeAnalysis (>= 1.0.0-rc2)
      RazorEngine (>= 4.5.0-rc1)
    System.Collections.Immutable (1.4)
    System.Composition (1.2)
      System.Composition.AttributedModel (>= 1.2)
      System.Composition.Convention (>= 1.2)
      System.Composition.Hosting (>= 1.2)
      System.Composition.Runtime (>= 1.2)
      System.Composition.TypedParts (>= 1.2)
    System.Composition.AttributedModel (1.2)
    System.Composition.Convention (1.2)
      System.Composition.AttributedModel (>= 1.2)
    System.Composition.Hosting (1.2)
      System.Composition.Runtime (>= 1.2)
    System.Composition.Runtime (1.2)
    System.Composition.TypedParts (1.2)
      System.Composition.AttributedModel (>= 1.2)
      System.Composition.Hosting (>= 1.2)
      System.Composition.Runtime (>= 1.2)
    System.Reflection.Metadata (1.4.2)
      System.Collections.Immutable (>= 1.3.1)

GROUP Foo
RESTRICTION: == net45
NUGET
  remote: https://www.nuget.org/api/v2
    Elasticsearch.Net (5.6)

Run command paket add -g Foo Newtonsoft.Json

Expected behavior

No entries in the 'Main' section of paket.lock change

Actual behavior

The line
System.Collections.Immutable (1.4)
changes to
System.Collections.Immutable (1.5)

@forki

This comment has been minimized.

Member

forki commented Jun 19, 2018

@bacar

This comment has been minimized.

bacar commented Jun 19, 2018

Thanks. Enjoy your vacation!
Am I right in thinking that the first preference for resolving versions should be “the version that’s already in the lock file”?

Re lock file intent - I do think it’s important for paket’s behaviour to be mostly predictable; my team get very frustrated by it when it appears to inexplicably alter things (which they perceive as “random”), and this can make them dread using it, or they end up bypassing it entirely (which just causes problems later). As I find more examples I’ll raise tickets.

BTW is there a command that means “don’t touch the lock file — but update all the proj files (with all the redirects etc) to be consistent with the current lockfile”?

@inosik

This comment has been minimized.

Contributor

inosik commented Jun 19, 2018

is there a command that means “don’t touch the lock file — but update all the proj files (with all the redirects etc) to be consistent with the current lockfile”?

paket install should do that.

@bacar

This comment has been minimized.

bacar commented Jun 19, 2018

I don’t think that’s true. It doesn’t seem to always leave the lock file alone. The doc says:

Unlike paket update, paket install will only look for new versions of dependencies that have been modified in paket.dependencies and use the version from paket.lock for all other dependencies.

I’m not sure how it defines “new versions of dependencies that have been modified in paket.dependencies”.

Wondering if I ought to take this branch of the question elsewhere...?

@forki

This comment has been minimized.

Member

forki commented Jun 19, 2018

@bacar

This comment has been minimized.

bacar commented Jun 19, 2018

OK thanks. That works — modulo this current ticket.
I can’t work around the problem in the current ticket using --keep-patch because install also suffers from the same problem I outlined in issue #3257 if you use --keep-patch

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