Latest wheel==0.32.0 breaks multibuild/supported_wheels.py

[anthrotype]

this was just released today: https://pypi.org/project/wheel/0.32.0/

the supported_wheels.py script in multibuild is now failing with the latest wheel version with this error:

Traceback (most recent call last):
  File "/io/multibuild/supported_wheels.py", line 8, in <module>
    from wheel.install import WheelFile
ModuleNotFoundError: No module named 'wheel.install'

https://travis-ci.org/fonttools/openstep-plist/jobs/435053641#L590

[anthrotype]

as temporary workaround, pinning wheel==0.31.1 in TEST_DEPENDS seems to work
fonttools/openstep-plist@e4e7abf...d50f6a8

[anthrotype]

also delocate seems broken by wheel 0.32.0 (but you probably know that already)
https://travis-ci.org/fonttools/openstep-plist/jobs/435056896#L177

[anthrotype]

@matthew-brett I see you've opened an issue on the wheel repo, thanks for taking a look to quickly! 👍

[matthew-brett]

Thanks for letting me know. I made a fix on the devel branch - does it work for you? I'll fix, release delocate now too.

[anthrotype]

thanks, I'll try

[anthrotype]

it's now failing with

AttributeError: 'WheelFile' object has no attribute 'tags'

I'll pin to 0.31.1 for now.

[anthrotype]

travis build log with full traceback here:
https://travis-ci.org/fonttools/openstep-plist/jobs/435064653#L589-L594

[matthew-brett]

Oh man, they've really gone to town on refactoring the API. I think the official wheel project position is "don't care, you shouldn't be using it anyway" : pypa/wheel#255 (comment) . I've made the case over at that issue, but pip did the same thing, hoping it would make their lives easier. I think that didn't work for pip, but we'll see what happens for wheel.

[hugovk]

Seeing this on a Mac build:

Installing collected packages: delocate
Successfully installed delocate-0.7.3
Traceback (most recent call last):
  File "/Users/travis/build/hugovk/pillow-wheels/venv/bin/delocate-wheel", line 15, in <module>
    from delocate import delocate_wheel, __version__
  File "/Users/travis/build/hugovk/pillow-wheels/venv/lib/python2.7/site-packages/delocate/__init__.py", line 3, in <module>
    from .delocating import delocate_path, delocate_wheel, patch_wheel
  File "/Users/travis/build/hugovk/pillow-wheels/venv/lib/python2.7/site-packages/delocate/delocating.py", line 18, in <module>
    from .wheeltools import rewrite_record, InWheel
  File "/Users/travis/build/hugovk/pillow-wheels/venv/lib/python2.7/site-packages/delocate/wheeltools.py", line 14, in <module>
    from wheel.util import urlsafe_b64encode, open_for_csv, native
ImportError: cannot import name open_for_csv

https://travis-ci.org/hugovk/pillow-wheels/jobs/435064485#L4899

[matthew-brett]

Yes, sorry, the API for wheel has completely changed, wreaking havoc with delocate, in particular. I'm working on it now.

[charris]

WheelFile is in wheel.wheelfile

In [1]: from wheel.wheelfile import WheelFile

In [2]: 

[matthew-brett]

Chuck - thanks - yes - but the wheel folks have done a huge refactoring of their internals, so it's much worse than just a moved import, sadly.

[charris]

If wheel has no public API, why does it exist?

[charris]

Hi @matthew-brett , I'm feeling your pain :) The easiest short term fix is probably to pin the release version.

[hugovk]

It exists as (1) a setuptools extension and (2) a command line tool, according to the README:

https://github.com/pypa/wheel/blob/master/README.rst

[hugovk]

The latest devel of multibuild is now passing for Linux, and as expected Mac builds are failing due to delocate:

https://travis-ci.org/python-pillow/pillow-wheels/builds/435238329

We're due for a quarterly Pillow release tomorrow (2018-09-01). Is delocate fixed in master, and if so, any chance of a release today or tomorrow? Or would it help if we tested it first, and is there anything else we can do to help?

Thank you!

[hugovk]

Actually no rush, we're all good with pinning wheel (Linux and Mac) and I don't see anything really important where we would need the new wheel version.

[anthrotype]

just noting that auditwheel is now failing as well (even after I set VIRTUALENV_NO_DOWNLOAD=1), as the manylinux docker images now ship with wheel 0.32.0 pypa/manylinux#228

https://travis-ci.org/fonttools/openstep-plist/jobs/435504919#L545

I have set wheel==0.31.1 in both BUILD_DEPENDS, TEST_DEPENDS, in pyproject.toml and have VIRTUALENV_NO_DOWNLOAD=1.

[matthew-brett]

See: pypa/manylinux#229

[anthrotype]

Thanks!

[charris]

@matthew-brett What is the status of this? Should we just go ahead and pin the wheel version? I'm looking to make a release next weekend.

[matthew-brett]

There's no harm in pinning, but it's not needed any more.

[radarhere]

Cool, thanks @matthew-brett. So is there anything keeping this issue open?

[charris]

@matthew-brett I assume we need to update the multibuild submodule hash?

[matthew-brett]

Yes, it should be latest master or devel.

[mattip]

Closing, currently as far as I know all the pieces are in place to use the latest wheel version. Please reopen if I am mistaken.