-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3.8 wheels on PyPI #11
Comments
This PR makes it so we _always_ build manylinux wheels, but only upload them for git tags. Highlights: - Move regular Linux Python builds outside the build matrix, for conciseness. - Switch manylinux1 builds to manylinux2010 (they should still get the manylinux1 tag if they're compatible, but they'll be built with a more modern compiler toolchain). - Move twine upload from .manylinux.sh into .travis.yml's after_success, right next to the twine upload used for Mac OS builds. - This means we can't short-circuit the builds with 'exit 0' in before_install:, so overwrite the install: and script: sections too. - Move the 'docker pull' from .manylinux.sh into the install: section so it's not empty. - Provide twine credentials via environment variables instead of command-line/pypirc file. - Put related commands inside a single multiline if statement. - Use setup.py -q test (quiet build) instead of setup.py test -q (which does nothing at all AFAICT). This mirrors changes made to other zopefoundation packages tracked in zopefoundation/meta#11.
This brings our travis configuration in line with the rest of the packages. See zopefoundation/meta#11.
Current status:
(table generated with https://github.com/mgedmin/check-pypi-wheels). Missing wheels:
|
Python 3.5 on Mac OS doesn't support TLS 1.2, which makes twine upload fail, but we can use system Python 2.7 for twine upload, which works. Also brings the rest of the Travis CI configuration closer in line to the rest of the packages updated for zopefoundation/meta#11
Python 3.5 on Mac OS doesn't support TLS 1.2, which makes twine upload fail, but we can use system Python 2.7 for twine upload, which works. Also brings the rest of the Travis CI configuration closer in line to the rest of the packages updated for zopefoundation/meta#11
I'm done working on this. |
Meanwhile things have progressed somewhat:
We have a slight regression (persistent MacOS wheel for Python 3.5 failed to build), and also slight improvement (persistent has Python 3.8 MacOS wheels now). Would anyone care to copy and paste the Mac OS 3.8 build snippet from persistent's .travis.yml to all the other packages? |
@mgedmin zope.interface got Py3.8 MacOS wheels on master and 4.7 but it is not yet released. Should I change your table to add it there or what is the plan? |
The table shows what's available to the users. We could backport the travis changes to a temporary branch and hack out the "only tags" restriction to build an upload the missing wheels for the existing releases, but this is complicated and error prone. We can wait for the next release or until a user complains. Meanwhile I see zope.hookable and zope.i18nmessageid got Mac 3.8 wheels, and persistent even has Mac 3.9 wheels despite Python 3.9 not being out yet. Let's hope 3.9 final won't break ABI compatibility with whatever alpha prerelease is out yet! |
Okay, let's wait for the new releases to be made. |
I added the snipped to add 3.8 MacOS wheels for
I removed 3.9 MacOS wheels from: (Let's wait until the final release.)
I think this issue can be closed again. Agreed? |
Sure! |
It would be nice to have Python 3.8 wheels for Windows at least (Linux users tend to have C compilers) published on PyPI for all zopefoundation packages that have extension modules.
I've been tackling this one by one, but there are more of the packages than I've remembered, so I've decided to file one tracking issue here.
Scope creep:
Out of scope because oh come on, please somebody else step up to do these I have enough work as it is:
Packages that have extension modules (found by doing a
grep twine */appveyor.yml
on all repos):The text was updated successfully, but these errors were encountered: