[CPVM-OnBoard] Implicit flow of transitive dependencies

[cristinamanum]

Details about Problem

Feature Request
Issue details from customer

I really hope this doesn't become the new packages.config that was so hard to maintain since updating one package meant having to update so many other packages just so that the set of versions was coherent.
In this new CPV world, I'm seeing something very similar cropping up. Here's the scenario:
• Package A references package B
• Some projects reference A while others reference B
• I now have to specify the version for both A and B in my Directory.Packages.props
• When I bump the version of A, I often get a warning that I am downgrading the version of B. I have to manually update B too.
Key point: What I'd like to do is just specify Package A's version in my CPV file. The transitive closure of dependencies that specify B should imply a unified version of B in my repo so that anyone who references B directly automatically gets the same version that A points to.
Explicitly specifying a version for B should of course be allowed.
The above scenario is the reduced form of what is actually a very large package graph. We have a metapackages or deep dependency trees yet projects frequently reach into many parts of that tree. I would much rather maintain just a few "top-level" package versions and let them automatically imply the versions that everyone should use who reach for only some subtrees of it.

Scenarios and expectations
Case 1:
PackageA 2.0.0 -> PackageB 2.0.0
ProjectA -> PackageA
ProjectB -> PackageB

Directory.Packages.props

    <PackageVersion Include=”PackageA” Version=”2.0.0” />

Desired output:
Restore ProjectB resolve the PackageB to version 2.0.0

Case 2:
PackageA 2.0.0 -> PackageB 2.0.0
ProjectA -> PackageA
ProjectB -> PackageB

Directory.Packages.props

    <PackageVersion Include=”PackageA” Version=”2.0.0” />
    <PackageVersion Include=”PackageB” Version=”3.0.0” />

Desired output:
Restore ProjectB resolve the PackageB to version 3.0.0
Restore ProjectA resolve PackageB to version 3.0.0

Case 3:
PackageA 2.0.0 -> PackageB 2.0.0
PackageC 3.0.0 -> PackageB 3.0.0

ProjectA -> PackageA
ProjectB -> PackageB

Directory.Packages.props

   <PackageVersion Include=”PackageA” Version=”2.0.0” />
   <PackageVersion Include=”PackageC” Version=”3.0.0” />

Desired:

I would suggest we consider that just like we would if ProjectB referenced PackageA and PackageC: fail with an ambiguity and require that PackageB now be added to the Directory.Packages.props file.
The alternative I guess would be to take the higher of the two. But I don't think that's how nuget version conflicts are resolved today, and I can live with your current policy there.

[cristinamanum]

Added customer repo and comments for the requested feature.
cpvmtest.zip

_...his is exactly the scenario I expect to work. StreamJsonRpc includes Newtonsoft.Json as a dependency, so by "fixing" a version of StreamJsonRpc it should implicitly "fix" all packages included in its transitive closure as well.
This is so important for the app SDK development scenario, where it is critical to match an app dependencies in an extension of that app. The app  may ship a bunch of nuget packages and a meta-package to loop them all in. Extensions just want to target one version of the app so they 'pin' the meta-package version, then they proceed to just use any package they require without worrying about versions at all until they need a package that isn't already included in the app. _

[AArnott]

In discussion with the NuGet team, we determined that this request is perhaps untenable, because the full transitive graph of all possible packages in the whole repo would have to be restored and analyzed for even just one project to be restored, just to see if any of the packages mentioned in Directory.Packages.props happened to include transitive dependencies to the packages that the one project consumed to see how these versions would be influenced.

Our best bet then is a tool that we can run on the Directory.Packages.props file to help us specify consistent versions.

[jeffkl]

Closing as unplanned