Work around PyPI not working on Windows in Travis

[aiudirog]

@frozencemetery When you get a chance, see if this fixes the wheel deployment for now. I just need you to replace the template credentials with the encrypted ones.

[aiudirog]

Adding tag back to issue. #32

[frozencemetery]

Hi @aiudirog, thanks for the PR. I'm doing some test builds with it - deploys are very slow so it will take a while.

One important change I've had to make is around environment variables: Windows build log obfuscation doesn't seem to work (per here) so this will take several attempts.

[frozencemetery]

Fun fact: pip reads all env vars of the form PIP_NAME=VALUE as if they were passed as arguments pip --name=value.

[aiudirog]

Looks like they still have a lot to improve. One other thing that might work is building the wheels after testing and dumping them somewhere to be picked up by the Linux before-deploy.sh.

---

It does the same thing with pip.conf. I remember spending a while trying to find what options could be used in it and it took longer than I care to admit to realize it was just all command line options.

[frozencemetery]

@aiudirog Do you have ideas on how to do that, or should we just give up and hand-upload Windows wheels for now?

[aiudirog]

Travis seems to recommend storing artifacts which need to persist between build stages in an S3 bucket. The free tier would probably work perfectly for it.

Nevermind, that seems like it would have the same issue with credentials being exposed in logs. I'll do some research and see if there is a secure solution.

[aiudirog]

@frozencemetery This sounds like a hack but it might work: we use s3 deployment on the individual Windows build steps to upload the wheels and then add a 4th stage which runs in a Linux container that just pulls the wheels back and uploads them to PyPi. Alternatively, we move the Windows deploy stages above the Linux one so that they run first and then have the Linux one grab and upload the wheels without adding the extra dedicated stage.

If that sounds too hacky, at first glance AppVeyor appears to be mostly cmd/PowerShell so more than expected might have to be implemented to get it running. Hand uploading might actually be the most painless way to go until this issue is resolved. I do all of my Windows work in a dedicated VM so I could build the wheels and ship them over to you whenever there is a release or we could work something else out.

Thoughts?

[frozencemetery]

So I've got a branch that successfully uploads to pypi - you can see the wheels are successfully present on the download page. The problem is that this bypasses Travis's deploy logic entirely - I need to turn it off. I think this is easy, but Travis is having stability issues right now, so this will probably have to wait another day.

When that's done, I'll squash it all and cut 1.6.1. After that, I want to look into paring down our test matrix - this takes forever to run, and having this many discrete travis items exposes us to many infrastructure failures Travis has. Probably we can eliminate the verify stage, and then in January we can drop out all the python2 builders.

[frozencemetery]

(Superseded by #180.)