samhowes
commented
3 years ago I've done some thinking on this topic over in @rules_msbuild, thought I'd share what I've learned:
Bazel brings a unique challenge to the table for using Directory.Packages.props: NuGet packages have different dependency graphs for each target framework that the NuGet package supports.
Take NewtonSoft.Json for example: NETStandard 2.0 has no dependencies.
.NETStandard 1.0 depends on:
- Microsoft.CSharp (>= 4.3.0)
- NETStandard.Library (>= 1.6.1)
- System.ComponentModel.TypeConverter (>= 4.3.0)
- System.Runtime.Serialization.Primitives (>= 4.3.0)
Directory.Packages.props only specifies the PackageId, but does not specify the frameworks to restore for. If a workspace only uses Netstandard2.0, and an implementation fetches the packages ahead of time without knowing what projects it is fetching for, then a naive implementation could end up fetching a bunch of NuGet dependencies for Netstandard1.0 that arent needed.
Over in @rules_msbuild, I accommodated this with a similar approach to Directory.Packages.props, but with a slight tweak: I specify the PackageId, and then the list of frameworks that depend on it. This way, packages can be fetched ahead of time without loading build files, and no unnecessary packages are fetched.
Example format automatically managed by @rules_msbuild//gazelle/dotnet
nuget_fetch(
name = "nuget",
packages = {
"NewtonSoft.Json/13.0.1": ["net5.0", "netstandard2.1"], # no transitive dependencies will be fetched
}
)Given that a Directory.Packages.props file is just another project file to msbuild, this likely could also be handled by simply added metadata to the Package item, so long as that metadata name doesn't conflict with MSBuild's normal metadata for Packages:
<Project>
<ItemGroup>
<PackageReference Include="NewtonSoft.Json" Version="13.0.1">
<TargetFrameworks>net5.0,netstandard2.1</TargetFrameworks>
</PackageReference>
</ItemGroup>
</Project>It would be a slight departure from the standard feature set of the Directory.Packages.props file, but definitely something that an automated tool could manage. @rules_msbuild//gazelle/dotnet would certainly be capable of outputting into this format with a little work on merging the XML files.
Automation is ideal for this type of Package management that specifies the TargetFramework, because the user would be required to maintain the TargetFramework in two places: once in the project file of the target assembly, and another place for bazel to know what dependency graph to fetch ahead of time.
Alternatively, the nuget tool could somehow parse all of the project files in the workspace that have packages specified, but that seems to be counter to Bazels approach of Loading, Analysis, and Execution separations. You would also most likely have to actually evaluate the project files, which is starting to encroach on performing an actual build.
Just my two cents!
tomdegoede
purkhusid
hsyed-dojo
njlr
Place1
Robust dependency management
Participants: @hsyed-dojo and @tomdegoede Reviewers: @purkhusid
Dependency management is arguably the most complex aspect of managing a Bazel build at scale. A dependency management solution is needed that will work ergonomically in a dual build setup (msbuild and bazel). This is one of the ingredients for full build generation #258 and is one of the changes we would like to bring in for increased adoption of these official rules #260.
We propose a solution that follows the developer experience, mechanics and patterns in use by rules_jvm_external.
Dotnet builds have a convention in the works for centralising the dependencies of a project. A top level
Directory.Packages.propsis a manifest for all the coordinates and versions in use by a solution. We propose that this file become the standard way of encoding dependencies for projects that use these rules.Core points:
@nuget.rules_jvm_externalwe will have a custom/expanded lock file format to populate the dependencies. An expanded format would be preferable because we can then share this with msbuild.