Share custom package infra among tools projects #46098
Conversation
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
| @@ -1,6 +1,7 @@ | |||
| <Project> | |||
|
|
|||
| <Import Project="$([MSBuild]::GetPathOfFileAbove(Directory.Build.props, $(MSBuildThisFileDirectory)..))" /> | |||
| <Import Project="$(CustomPackageVersionsProps)" Condition="'$(CustomPackageVersionsProps)' != ''" /> | |||
There was a problem hiding this comment.
There are other existing tools in this directory besides BinaryToolKit. It would be good to not add more complexity to those tools (especially the msbuild tasks). Can you describe why you can't copy the Import in BinaryToolKit into the new project that will get added?
Aside, I see some benefit in having only a single entry point project for these different kind of permutations. Would it make sense to rename BinaryToolKit to something more generic and make it possible to invoke it for the different scenarios? If you use System.CommandLine it has support for subcommands which might be appropriate here.
There was a problem hiding this comment.
Can you describe why you can't copy the Import in BinaryToolKit into the new project that will get added?
I want to be able to invoke the standalone CLI tools in eng/tools via a single script which takes --tool <tool> and optionally --with-packages and --with-sdk as arguments. It felt complex to try to condition the --with-packages arg to only be allowed when the tool supports the CustomPackageVersionsProps prop. So, rather than condition the script's --with-packages arg, I felt that it would be best to allow the projects in this directory to have the ability to optionally use the prop + infra.
I see some benefit in having only a single entry point project for these different kind of permutations
I see your point in this. I'm open to moving the current standalone tools (CreateBaselineUpdatePR, BinaryToolKit, LicenseRemover) into a new directory with shared targets and props, but I'm hesitant to move them all into a single project because the tools aren't all directly related in their actions/purposes.
There was a problem hiding this comment.
but I'm hesitant to move them all into a single project because the tools aren't all directly related in their actions/purposes.
Agreed, the CreateBaselineUpdatePR one doesn't make sense to merge with the others. In general see value in having one managed "prep build tool". That would mean merging BinaryToolKit and LicenseRemover together. I assume that they already share some basic knowledge on how to traverse the source graph and exclusions handling. Just a suggestion as I think a common managed project would make things more scalable in the future.
Needed for new tooling that will be added as part of dotnet/source-build#4736