build+publish updated wheels for the 1.12 release #2849

New Issue

warner · 2016-12-14T20:53:50Z

warner commented

2016-12-14 20:53:50 +00:00

(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.

(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.

warner added the

labels 2016-12-14 20:53:50 +00:00

warner added this to the 1.12.0 milestone 2016-12-14 20:53:50 +00:00

warner self-assigned this 2016-12-14 20:53:50 +00:00

Brian Warner <warner@lothar.com> commented

2016-12-15 00:13:47 +00:00

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

In [1748e73/trunk](/tahoe-lafs/trac-2024-07-25/commit/1748e735996698943ea38a5e8602a8b24ebab900): ``` 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 ```

warner commented

2016-12-15 00:21:06 +00:00

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.

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.

warner added the

fixed

label 2016-12-15 00:21:06 +00:00

warner closed this issue

2016-12-15 00:21:06 +00:00

warner commented

2016-12-24 22:49:55 +00:00

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

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

Sign in to join this conversation.