An AppVeyor build was created:
https://ci.appveyor.com/project/dhermes/gcloud-python/build/1.0.1.master

https://bugs.python.org/issue14243

@tseaver After running

python setup.py bdist_wheel

we get a none-any wheel:

ls dist

    Directory: C:\projects\gcloud-python\dist


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        11/16/2015   5:39 PM     402514 gcloud-0.8.0-py2-none-any.whl
-a---        11/16/2015   5:39 PM     601288 gcloud-0.8.0.win32.exe
-a---        11/16/2015   5:39 PM     737280 gcloud-0.8.0.win32.msi

Any idea what needs to be done to have a Windows specific wheel?

As far as getting up and running on AppVeyor, I still need to

• get tox working
• figure out how to upload the MSI/EXE/wheel to an existing version

The python-appveyor-demo project was SOOOO helpful here.

Any idea what needs to be done to have a Windows specific wheel?

We don't have any C extensions, so a "universal" wheel should work fine on Windows. See: http://wheel.readthedocs.org/en/latest/#defining-the-python-version .

Ahhh I see. The downstream deps don't matter for making a wheel.

I'm curious if they're bundled in the exe/MSI (that was the purpose of #1009, that the crypto deps were a pain and it would be nice for us to bundle them).

Seems I'll end up tackling #1123 as well in tackling #1124 (funny how the numbering worked out that way).

@tseaver A few notes here.

Getting tox to work is going to be difficult since every command in AppVeyor needs to be run in a special environment. This would mean over-riding install_command in tox.ini, but we wouldn't want to do that on all Windows machines, just the AppVeyor ones.

I just took the easy way out and used

%CMD_IN_ENV% python setup.py nosetests

to run the tests.

The script builds bdist_wininst and bdist_msi but they aren't clearly labeled by version (see below). I'm curious if we should upload one of these for all 8 possible environments (32- or 64-bit and then 4 Python versions 2.6, 2.7, 3.3 and 3.4) and if the actually files are different from version to version.

• Python 2.6.6 32 bit

gcloud-0.8.0.win32-py2.6.msi
gcloud-0.8.0.win32.exe

• Python 2.6.6 64 bit

gcloud-0.8.0.win-amd64-py2.6.msi
gcloud-0.8.0.win-amd64.exe

• Python 2.7.10 32 bit

gcloud-0.8.0.win32.exe
gcloud-0.8.0.win32.msi

• Python 2.7.10 64 bit

gcloud-0.8.0.win-amd64.exe
gcloud-0.8.0.win-amd64.msi

• Python 3.3.5 32 bit

gcloud-0.8.0.win32.exe
gcloud-0.8.0.win32.msi

• Python 3.3.5 64 bit

gcloud-0.8.0.win-amd64.exe
gcloud-0.8.0.win-amd64.msi

• Python 3.4.3 32 bit

gcloud-0.8.0.win32.exe
gcloud-0.8.0.win32.msi

• Python 3.4.3 64 bit

gcloud-0.8.0.win-amd64.exe
gcloud-0.8.0.win-amd64.msi

@tseaver We don't actually need to get uploads (e.g. via twine) working if we don't wish to.

AppVeyor gives direct access to the artifacts for a build:
https://ci.appveyor.com/project/dhermes/gcloud-python/build/1.0.38.master/job/q3tgnrskftxxdi6d/artifacts
so we could just download them and upload by hand to PyPI (though it appears uploading to PyPI on AppVeyor may be a solved problem)

Unless we figure out how to get those artifacts built correctly (with appropriate names), uploading them to PyPI is kind of moot.

I was curious if you knew what a "correct" name was. They were produced directly by setuptools, so maybe that is what they are supposed to look like? Right now I'm scouring other projects to see if they have any MSIs (none on numpy, for example).

https://pypi.python.org/pypi/zope.interface/4.1.3 has separate installer EXEs for each supported Python.

Awesome resource, thanks! Do you know how they are created? Maybe someone manually changes the filename?

From https://docs.python.org/2/distutils/builtdist.html

If you have a pure module distribution (only containing pure Python modules and packages), the resulting installer will be version independent and have a name like foo-1.0.win32.exe. These installers can even be created on Unix platforms or Mac OS X.

If you have a non-pure distribution, the extensions can only be created on a Windows platform, and will be Python version dependent. The installer filename will reflect this and now has the form foo-1.0.win32-py2.0.exe. You have to create a separate installer for every Python version you want to support.

This worries me that the dependencies (e.g. pycrypto, the annoying one) aren't bundled up in the msi file. I was hoping for a magic pill.

I'm positive that dependencies aren't bundled: we'd have to vendor them in.

RE:

I'm positive that dependencies aren't bundled: we'd have to vendor them in.

I have (hopefully) addressed in #1338. Will close this PR and open a more polished version once #1338 is in.