Re-land: Added virtualenv for depot_tools

update_depot_tools

Index: update_depot_tools
diff --git a/update_depot_tools b/update_depot_tools
index 8528b8bab511e07099a54542c43aac3e58b1f508..e0984c1a0bef55905d68ca4cac78759c9f577b14 100755
--- a/update_depot_tools
+++ b/update_depot_tools
@@ -153,3 +153,17 @@ then
 fi
 
 find "$base_dir" -iname "*.pyc" -exec rm {} \;
+
+# Initialize/update virtualenv.
+VIRTUALENV_REPO="https://chromium.googlesource.com/infra/third_party/virtualenv.git"
+VIRTUALENV_REVISION="4243b272823228dde5d18a7400c404ce52fb4cea"

[pgervais, 2015/06/24 16:31:33]

Virtualenv is vendored in infra.git/bootstrap/virtualenv, we should do the same
here (put it in third_party instead if you want).

We really don't want to depend on yet another network connection on all slaves.

[Sergiy Byelozyorov, 2015/06/25 14:42:17]

It's checked out with DEPS. I thought 'vendored' means 'copied'. We can't use
DEPS here since gclient is not set up yet. Also there are other commands using
network here... why adding another one makes it worse?

[pgervais, 2015/06/25 17:12:02]

Yes 'vendored' means copied. The idea behind Glyco is to vendor everything (in
depot_tools) anyway.

I ack the fact that this file uses the network already, but it's also a question
of atomicity. If git fetch fails, no big deal. If git fetch succeeds but
downloading virtualenv fails, we end up in  a weird situation. BTW with the
current code we have no way to update virtualenv. We'll need some more logic to
fix it, which can also break, etc. The simpler the better.

[Sergiy Byelozyorov, 2015/06/25 17:34:51]

Done.

+cd $base_dir
+if [ ! -d bootstrap/virtualenv ]; then
+  echo "Fetching virtualenv from $VIRTUALENV_REPO@$VIRTUALENV_REVISION"
+  eval "$GIT" clone "$VIRTUALENV_REPO" bootstrap/virtualenv --no-checkout --quiet
+  cd bootstrap/virtualenv
+  eval "$GIT" checkout "$VIRTUALENV_REVISION" --quiet
+  cd ../..
+  echo "Done fetching virtualenv"
+fi
+python -u ./bootstrap/bootstrap.py --deps_file bootstrap/deps.pyl --quiet ENV