I didn't find a root cause (though I suspect setuptools is being overly clever), but I found a work-around. It's unsatisfactory, but I managed to create wheels that seem to work by renaming the dist directory after each setup command, like this:

rm -rf dist
python2 setup.py bdist_wheel
mv dist dist2
python3 setup.py bdist_wheel
mv dist dist3
python3 setup.py sdist

After this I can move the wheels back into dist and run twine, but I'll hold off until someone has reviewed this procedure.

Also the source dist created by the last step has way more files than the 3.6.1 source dist (I suspect setuptools here too). I propose to manually prune the tarball so it contains these files only:

typing-3.6.2/
typing-3.6.2/LICENSE
typing-3.6.2/PKG-INFO
typing-3.6.2/python2/
typing-3.6.2/README.rst
typing-3.6.2/setup.cfg
typing-3.6.2/setup.py
typing-3.6.2/src/
typing-3.6.2/src/mod_generics_cache.py
typing-3.6.2/src/test_typing.py
typing-3.6.2/src/typing.py
typing-3.6.2/python2/mod_generics_cache.py
typing-3.6.2/python2/test_typing.py
typing-3.6.2/python2/typing.py

@gvanrossum hmm, this is odd. It's probably weird manifest.in stuff.

I'd probably recommend creating a universal wheel that picks module at runtime.

I'd probably recommend creating a universal wheel that picks module at runtime.

I had the same idea. At least IIRC I have seen other libs on PyPI do this.

This is the version I intend to release as typing 3.6.2, except that I just found there's a problem with the py3 wheel -- it is identical to the py2 wheel. I'll try to debug.

I get two different wheels and an sdist when I run:

workon some3venv
rm -rf dist
python3 setup.py bdist_wheel
workon some2virtualenv
python2 setup.py bdist_wheel
python2 setup.py sdist

eg: dist.tar.gz

@gvanrossum can you repeat your problem in docker/vagrant/on travis ?

Try using Travis PyPI deploy

Try using Travis PyPI deploy

I'm sorry I have no idea what that means (I'm not much of a Linux admin or devops person).

Anyways I'm sure the problem is due to some setup on my system. I have to focus on other stuff first today.

@gvanrossum create a new user on pypi.org eg "typing-bot" and give it maintainer access to typing on PyPI.

then run through the steps here, with that user:

https://docs.travis-ci.com/user/deployment/pypi/

I have no intention to let Travis install anything before I've built and tested the wheels.

@gvanrossum you can configure it to point at the testing PyPI service, then promote the wheels

All I know is that the sequence you use creates two identical wheels, even in a clean checkout, both based on the first run. There much be some caching going on.

Ah this appears to be due to:
https://bitbucket.org/pypa/wheel/issues/147/bdist_wheel-should-start-by-cleaning-up

Adding an rm -rf build/ between the two pythonXX setup.py bdist_wheel calls will resolve that.

I could swear I had tried that, but apparently not, because it works. I will do the release now.

OK, done. Someone please verify: https://pypi.python.org/pypi/typing/3.6.2

@ilevkivskyi When you approve of the release, can you merge this PR?

Thanks! Everything works perfectly.

Ah I guess the README section for releases needs updating too?
https://github.com/python/typing#workflow-for-pypi-releases

@edmorley Yes, would you like to make a PR?