#2849 closed task (fixed)

build+publish updated wheels for the 1.12 release

Reported by: warner Owned by: warner
Priority: normal Milestone: 1.12.0
Component: packaging Version: 1.11.0
Keywords: Cc:
Launchpad Bug:

Description

https://tahoe-lafs.org/deps/ currently holds pre-built wheels for MacOS-X and win32/win_amd64. Our docs/INSTALL.rst and docs/windows.rst recommend using it to avoid the need for a compiler.

We need to update the wheels there for the upcoming release. These should probably come from the appveyor and travis OS-X builders.

Change History (3)

comment:1 Changed at 2016-12-15T00:13:47Z by Brian Warner <warner@…>

In 1748e73/trunk:

Merge branch '2849-wheels'

This sets up Appveyor to create "build artifacts" which include zipfiles of
generated platform-specific wheels (now for both 32-bit and 64-bit).

It also updates the travis config to use the default OS-X platform (10.11 at
the moment), rather than an old one. (when we first enabled travis for OS-X,
the default was too old, and we had to force a newer one, but time has
marched on, and the "newer" one we picked has since become older than the
default). I haven't yet found an easy way to get OS-X wheels as Travis build
artifacts, so I'll create those manually for now.

refs ticket:2849

comment:2 Changed at 2016-12-15T00:21:06Z by warner

  • Resolution set to fixed
  • Status changed from new to closed

I used the Appveyor-generated windows wheels (both 32-bit and 64-bit), and combined them with the unique wheels from my home OS-X box (preferring the OS-X -generated ones where they overlapped), and uploaded them all to https://tahoe-lafs.org/deps/ . So we can close this for 1.12, assuming no updates happen between now and the release.

In the longer run, it might be useful to change the docs to recommend separate URLs for OS-X, win-32, and win-64, so we can have our CI systems automatically upload generated wheels into the right place.

The manual merge process was annoying. Platform-specific wheels with compiled C code are obviously unique, so we have one of them in the combined directory for each supported platform (this includes pypiwin32, which doesn't even exist on the OS-X build). Non-platform-specific wheels which our CI obtained by downloading them from PyPI were identical, so it didn't matter which build I pulled it from. But a couple of wheels were built from sources, and despite being "non-platform-specific", the generated wheels were different. I investigated briefly and found differences in newline formats in generated files (dist-info metadata like RECORD and WHEEL, Versioneer-generated _version.py, and unknown differences in .pyc files).

OTOH, the docs are certainly easier to follow when there's only one URL to add, regardless of platform.

comment:3 Changed at 2016-12-24T22:49:55Z by warner

Oops, I forgot about #2763 and included a wheel for Tahoe itself, and our build process doesn't correctly express the windows-only pypiwin32 dependency. So the presence of that wheel causes windows installations to fail.

I'll remove the wheel (again) and make #2763 a requirement for 1.13

Note: See TracTickets for help on using tickets.