Paket updates dependency in unrelated group #3259
Comments
|
The lock file is not to keep changes tight between commands. It's primarily
about reliable restore. That said this sounds like a a bug. But will take a
while - I'm still on vacation for 2 weeks.
bacar <[email protected]> schrieb am Di., 19. Juni 2018, 00:08:
… 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 (given that I have framework: net45)
and nothing I've referenced elsewhere mentions 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.3.1 to 1.5.
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 constraints over what I change and when, and that it
would prefer to keep things unchanged if it can, unless I specifically ask
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 make isolated updated too add/remove
individual dependencies 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 Newtonsoft.Json
(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 am
trying to update Newtonsoft from 9.0.1 to 11.0.2 in group Foo, I can't do
this whilst specifying --keep-patch to keep other unrelated dependencies
unaffected.
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.
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.3.1)
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.3.1)
changes to
System.Collections.Immutable (1.5)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3259>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgNBCl4C21AFv5FEiMbiE5GqJEwdHuks5t-CTLgaJpZM4UsjRh>
.
|
|
Thanks. Enjoy your vacation! 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”? |
|
|
I don’t think that’s true. It doesn’t seem to always leave the lock file alone. The doc says:
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...? |
|
Install will touch lock file when it thinks it's out of sync with deps file
bacar <[email protected]> schrieb am Di., 19. Juni 2018, 10:14:
… I don’t think that’s true. It doesn’t seem to always leave the lock file
alone, and the doc <https://fsprojects.github.io/Paket/paket-install.html>
doesn’t suggest that it will:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3259 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgNMFVa-o2coWS0H31XEAuhd0c9uxcks5t-LLYgaJpZM4UsjRh>
.
|
|
OK thanks. That works — modulo this current ticket. |
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.JsonNewtonsoft.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 ofSystem.Collections.Immutablein theMaingroup 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 updatespecific 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-patchbut this doesn't fully resolve the issue - I have the same problem whilst runningpaket 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 topaket updateit to 11.0.2, then I have to omit--keep-patch, but thenSystem.Collections.Immutableis 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 ofRazorEngine.Roslynso in other cases the behaviour is as I expect.Repro steps
Create
paket.dependenciesCreate
paket.lock:Run command
paket add -g Foo Newtonsoft.JsonExpected behavior
No entries in the 'Main' section of
paket.lockchangeActual behavior
The line
System.Collections.Immutable (1.4)changes to
System.Collections.Immutable (1.5)The text was updated successfully, but these errors were encountered: