augustoproiete
commented
1 year ago Hey @arturcic thank you for raising this and for the follow-up PR.
We discussed in the Cake team, and whilst Central Package Management seems like a cool feature at first glance, we don't think it makes sense for the Cake project at this point.
Cons
1. When we look at a package referenced by a project, it's very useful to know the version right away - With CPM we have to do a lookup on a different file (i.e. Directory.Packages.props) to find the version number
2. Adding and removing dependencies to different projects now has a bottleneck file Directory.Packages.props which means more potential for merge conflicts when multiple pull-requests add or remove dependencies to projects that otherwise would not cause conflict
3. It's not super easy to know when it is safe to remove a dependency from the Directory.Packages.props, as you don't know which projects are using it
4. It's not natural for the workflow most of us follow... When we need to add a dependency to. project, we go to nuget.org, find the package, copy the <PackageReference and paste in the .csproj and are done... With CPM we have an additional step to update Directory.Packages.props.
Pros
1. It ensures all projects use the same versions of packages
2. It makes it easy to spot all the dependencies used in a given repo
We don't think the Pros are good enough to make up for the Cons...
Nowadays with dependabot or renovate, it's easy to ensure all projects use the same versions of packages, and with tools like dotnet list package we can easily see the dependencies of projects and solutions.
Prerequisites
Cake runner
Cake .NET Tool, Cake Frosting
Cake version
3.0.0
Operating system
N/A
Operating system architecture
N/A
CI Server
No response
What are you seeing?
Not relevant
What is expected?
Not relevant
Steps to Reproduce
Not relevant
Output log
No response