From https://email@example.com/try-macosx64/try-macosx64-bm83-try1-build17126.txt.gz 15:54:55 INFO - Creating virtualenv /builds/slave/try-m64-0000000000000000000000/build/venv 15:54:55 INFO - virtualenv script: /builds/slave/try-m64-0000000000000000000000/scripts/virtualenv/virtualenv.py 15:54:55 INFO - Virtualenv /builds/slave/try-m64-0000000000000000000000/build/venv appears to already exist; skipping virtualenv creation. It surprised me that the virtualenv directory existed on a try push: try jobs are supposed to start with empty state. I performed a subsequent Try push where I performed a os.walk() on the virtualenv directory and sure enough, I saw a populated virtualenv, complete with requests and a few other Python packages. From IRC: 16:11 < gps> shouldn't try builds have empty state? 17:00 < aki> they should, but i don't think they're clobbered in mh clobber, so it expects runner or something external to nuke it 17:00 < aki> unless the venv is created under the work_dir, in which case it'll be clobbered along with work_dir 17:24 < gps> aki: thanks. i'll file a bug. 17:25 < aki> for try it might be easiest to move the venv into the work_dir, not sure how hard it is to get try runner to nuke venv I agree with aki: the virtualenv should be part of the working directory.