Windows bot provisioning uses "depot_tools" Git and Python bootstraps to install Git/Python for system use. These bootstraps are fragile and also something that we're looking at changing over the next few months, both in how they operate and how users interact with them.

Because of this, the standard workflow (e.g., checkout "depot_tools", run "gclient", have Python/Git) will likely change. Regardless, checking out a full "depot_tools" on systems just to get Python/Git is old hat; instead....

We have Windows CIPD packages for modern Python (2.7.13) and modern Git (2.13.2). These packages can be unpacked into an arbitrary directory using CIPD, and "just work". This is WAY more lightweight and robust than the "depot_tools" model, which makes it naturally more suitable for systems provisioning.

This is a long-term tracking bug to switch systems Windows bot provisioning methods from "depot_tools"-based toolchain to CIPD packages. The output of this is that:

1) "depot_tools" will no longer be a standard checkout on base bot systems.
2) "depot_tools" will no longer be in PATH by default.
3) Python and Git will be installed through their respective CIPD bundles using just CIPD,.
4) Systems tooling and bot scripts can still assume that "python" and "git" are in path for free, just like on Linux/Mac.

This covers ccompute Windows bots and systems VMs and baremetal bots.

This may be non-trivial and OKR-worthy.