On Mon, Jul 18, 2016 at 3:43 PM, Matthew Brett <[email protected]> wrote: > Hi, > > New Python versions are a real problem for our current wheel system. > When Python 3.5 came out, suddenly the default Python installed from > Python.org did not have any binary wheels ready for it, so an install > of scipy on OSX went from a few seconds to some very long time or a > crash if you didn't have the requirements. > > In order to avoid that, we'll need to make it easy to build and ship > wheels for upcoming Python releases. > > I just implemented that for OSX / travis-ci over at > https://github.com/matthew-brett/multibuild - you can add e.g. Python > version string `3.6.0a3` to build against, which downloads and > installs the pre-release installer for OSX. > > What to do about manylinux? I guess we need to have a pre-release > Python built on the docker image.
The problem here is that the 3.6 ABI will not be finalized until 3.6-final is actually released -- any wheels built on 3.6-prereleases could potentially segfault or whatever with the 3.6-final release. Hopefully this won't happen very often in practice, esp. for the later prereleases like the actual release candidates, but in principle it could happen. (For 3.5, the "final rc" was rc3... until they found a nasty problem with how they were building extension modules on Windows, which forced a last minute rc4 [1].) I agree that it would be really good to improve the UX for wheels on new Python releases, but I think it will require some discussion with the Python release managers (and possibly distutils-sig, in case we need finer grained Python version tags than just "3.6"). Definitely no-one should be uploading 3.6.0a3 wheels to PyPI :-) -n [1] http://stevedower.id.au/blog/building-for-python-3-5-part-two/ -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
