Add Python 3.8.0a2

[jcfr]

No description provided.

[jcfr]

Interestingly, local build fail indicating that no public key was found to verify the source archive:

[...]
+ local py_dist_dir=3.8.0
+ curl -fsSLO https://www.python.org/ftp/python/3.8.0/Python-3.8.0a2.tgz
+ curl -fsSLO https://www.python.org/ftp/python/3.8.0/Python-3.8.0a2.tgz.asc
+ gpg --verify Python-3.8.0a2.tgz.asc
gpg: Signature made Mon 25 Feb 2019 12:36:22 PM UTC using RSA key ID 10250568
gpg: Can't check signature: public key not found

Edit: Updating cpython-pubkeys.txt addresses this.

[jcfr]

@njsmith @matthew-brett This is ready for review and integration.

Cc: @thewtex

[trishankatdatadog]

@jcfr Yeah, I was about to suggest updating CPython pubkeys. I'll manually review the keys ASAP. Thanks!

[jcfr]

I'll manually review the keys ASAP

That would be stellar 🌟

(And getting this integrated soon would allow us to move forward with updating dockcross without having to publish built image somewhere else. 😄 )

As hinted here, I grabbed them from https://www.python.org/static/files/pubkeys.txt.

[trishankatdatadog]

LGTM:

~/pypa/manylinux$ shasum -a 256 docker/build_scripts/cpython-pubkeys.txt 
cc93a70d54978806c307c4a6727a68660cab6532a6e620a58dd63ffb35f92a29  docker/build_scripts/cpython-pubkeys.txt
~/pypa/manylinux$ curl -fSsLO https://www.python.org/static/files/pubkeys.txt
~/pypa/manylinux$ shasum -a 256 pubkeys.txt 
a619effbd71693068e75f31156b464155b76580ad1fd7bc76a75523f36e9f2d6  pubkeys.txt
~/pypa/manylinux$ diff pubkeys.txt docker/build_scripts/cpython-pubkeys.txt 
11542a11543
> 
~/pypa/manylinux$ 

[jcfr]

Thanks @trishankatdatadog for the helping out so quickly 🙏

[njsmith]

Uhhh... 3.8's ABI isn't set yet. It's not actually possible to make working manylinux wheels for it, because the ABI will change between now and the final release. What's the purpose of having it in the image? I feel like it's inevitable this will lead to broken wheels on PyPI...

[njsmith]

From a quick skim of linked issues, I didn't see any discussion of why this is useful, and lots of discussion of wanting to make 3.8 wheels.

Therefore I think we need to revert this ASAP, to protect people from themselves...

[jcfr]

Having 3.8 available is useful to setup testing and be ready for 3.8 actual release.

I think we need to revert this ASAP

Sounds good. Waiting 3.8 is released, we will upload the available image having Python 3.8 support on dockerhub so that we can have it in dockcross. Our plan is to start publishing wheel for Python 3.8 .. then when the stable release is out we will re-release and add .postN suffix to existing wheels.

[njsmith]

You can do whatever you like with your own packages, no skin off my nose :-).

You should be aware though that there are literally zero ABI compatibility guarantees for 3.8 until it's released. They might change the ABI every day between now and October, and based on past experience, probably will change it several times at least. So a single image probably isn't going to get you to the release.

[jcfr]

You should be aware though that there are literally zero ABI compatibility guarantees for 3.8 until

Considering that Python 3.8 is alpha, that makes sense.

For now, we will only publish wheels for cmake and ninja python packages. Since these bundle an executable, I don't expect any particular issue.

So a single image probably isn't going to get you to the release.

Indeed, we plan on updating the images each time a new alpha/beta/rc release of Python 3.8 is out.

[jcfr]

@njsmith @trishankatdatadog My apology for causing so much trouble. Here is the PR reverting #274

Cc: @thewtex

[njsmith]

No worries. Thanks for understanding!

For now, we will only publish wheels for cmake and ninja python packages. Since these bundle an executable, I don't expect any particular issue.

If you're just using a wheel as a container to ship a standalone executable, that doesn't actually use the Python C API, then there's an even better option: you can mark your wheels as py2.py3-none-manylinux1_amd64 (or the obvious variations for other platforms). That means:

• This wheel works with all python versions
• It doesn't depend on any particular C API
• It does require Linux/x86-64

This way you only have to ship one wheel per platform.