windows/gitian-pluggable-transports.yml downloads argparse
coderman on IRC noticed that the windows obfsproxy build downloads argparse (during "build", not "prep"):
Processing dependencies for obfsproxy==unknown Searching for argparse Reading https://pypi.python.org/simple/argparse/ Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:systray:initialize_systray Could not create tray window fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub Best match: argparse 1.2.1 Downloading http://argparse.googlecode.com/files/argparse-1.2.1.tar.gz#md5=2fbef8cb61e506c706957ab6e135840c Processing argparse-1.2.1.tar.gz
Now, the fact that setuptools may try to download dependencies is #10847 (closed), which we should try to inhibit by setting the http_proxy and https_proxy environment variables.
But apart from that, why did the descriptor start downloading argparse, when it didn't use to happen, and when the windows build uses Python 2.7, which includes argparse as standard? It started being downloaded in 8f8a4cd59b, which started calling the obfsproxy "install" target where only "py2exe" was called before.
LD_PRELOAD= $INSTPYTHON setup_py2exe.py py2exe + LD_PRELOAD= $INSTPYTHON setup.py install
It seems "py2exe" is able to find the standard library argparse dependency, but "install" is not. Hence setuptools attempts to download it.
I attach a candidate patch that builds argparse in the windows descriptor, just like in the mac and linux descriptors, even though it wouldn't be necessary if "install" could find the standard library version. This patch works, but is not so elegant and there might be a better way.