Permit defining native tools installation / OS

[chcosta]

Currently, if you define a native tool in global.json, it attempts to install on every OS (Windows / Linux). Many teams, just want native tools to be installed on Windows, but use Docker to provide native toolset dependencies on Linux. We need some method to specify appropriate OS' or to disable native toolset installation when running.

FYI @tmat, @ViktorHofer , @natemcmaster , @adiaaida

[ViktorHofer]

Why not just move away from defining native tools in the global.json file as that approach is not flexible at all. The native tools bootstrapping is already part of the restore phase of arcade. Why not define them as an ItemGroup in Tools.props instead? (or a NativeTools.props) There we can easily set msbuild conditions based on the OS.

[hoyosjs]

@chcosta We are hitting this again in CoreCLR. This causes hangs when we perform a restore, and the environment variable is not the best workaround right now as we use the restore flag all over the place. We've also hit it in some dev machines - particularly OSX. Do we have any recommendations here? Is it possible to go back to not restore by default? Other people complained that these are getting installed into their user directories during inner loop, even though a perfectly functional version was already in the the path. Disabling with the environment var is a workaround and so is skipping the installation by default. We still need to dig in why this hangs - even if we decide to go the msbuild route. On CI this gets our packaging step from under a min to a timeout after more than 40 mins.

cc: @sbomer @jkotas

[jkotas]

Other people complained that these are getting installed into their user directories during inner loop, even though a perfectly functional version was already in the the path.

+1.

I gave the same feedback on the early design for dealing with native dependencies. From #64 (comment) : But please do not download gigabytes of stuff for me by default when I have them in my Visual Studio installation already. Maybe not the exact version, but that's fine.

[ViktorHofer]

Sounds like a severe issue with a big impact. I'm fine making it an opt-in then.

I gave the same feedback on the early design for dealing with native dependencies.

+1

[chcosta]

#2911

Ack, I understand the pain here. Only thing to be aware of is https://github.com/dotnet/arcade/blob/51079d2f2412aa4923f9f2a4f78067f1045fbe8c/Documentation/Policy/ArcadeCommunications.md#types-of-engineering-services-change-communication. ie, we need to communicate any breaking changes with our partners.

FYI @MattGal @markwilkie @mmitche

[chcosta]

Did something change to exacerbate this issue or has this been causing problems for the past month?

[hoyosjs]

@chcosta We didn't have an arcade uptake for about a month due to SDK updates and msbuild issues. Once we fixed them, the solution was to comment the snippet @jkotas turned into a PR.

[chcosta]

I see. Makes sense, sorry for the pain! Let's continue to push to get this sorted. Likely it's going to take a few days. :(

[shawnro]

@chcosta, @riarenas, Do you have a complete list of requirements that are preventing folks from using the native bootstrapping? If not, please reach out to teams and gather it.

[chcosta]

I think this is largely encompassed by @MattGal's epic

This should be added - #4482

And we need to create an issue to track the "don't install more than you need to" request.

@MattGal , are you driving this? Do you have a list of repos that are using tools bootstrapping today? So we know which repos to talk to that aren't using bootstrapping and have reasons.

[riarenas]

That epic is not funded, it only has @MattGal's name because it's an issue he opened that got turned into an epic. There's no one driving that space right now.

The ask is for us to do the things you asked about 😃

[chcosta]

Cool, I guess I missed the part that this wasn't funded.

[chcosta]

I'll reach out to folks

[ViktorHofer]

dotnet/runtime uses native toolset bootstrapping partially but would like to use it through the bank to not depend on machine agent configurations like installed cmake versions. Please loop me into relevant discussions.

[markwilkie]

Snippet from @dougbu to better explain his thinking.

"native-tools": {
  "cmake": {
    "version": "3.11.1",
    "platform": "win"
  }
}

[riarenas]

Is this issue still relevant with the new world where bootstrapping dependencies in anything other than hosted mac machines is frowned upon? @MattGal @jonfortescue

[jonfortescue]

It is not. Closing.