Repository navigation
Release wheels for latest stable for Python 3.7 #3074
Description
Activity
I was able to on my mac, work around the issue by
brew install jpeg zliband then:$ LDFLAGS="-L$(brew --prefix zlib)/lib -L$(brew --prefix jpeg)/lib" CFLAGS="-I$(brew --prefix zlib)/include -I$(brew --prefix jpeg)" pip install pillow Collecting pillow Using cached Pillow-5.1.0.tar.gz Building wheels for collected packages: pillow Running setup.py bdist_wheel for pillow ... done Stored in directory: /Users/jaraco/Library/Caches/pip/wheels/1f/7f/91/4ffaae9e9681c72189fa211788eb26cacdce944e11371f6876 Successfully built pillow ...Would this project be interested in a mechanized build chain (such that tagged releases get built and uploaded with binaries to PyPI automatically)? I'd be willing to help put that together. I'd feel comfortable using Travis-CI for Linux and Mac and Appveyor for Windows.
I've uploaded the wheel I built to https://m.devpi.net/jaraco/dev/, so mac users may use that as their index-url for a temporary workaround.
Reacted by Jeffrey 'Alex' Clark and Mart Sõmermaa@jaraco I can't imagine we'd refuse such help …
Pillow-5.1.0 wheels for Python 3.7 for Windows are at https://pypi.python.org/pypi/Pillow/5.1.0. Pillow is also part of Winpython 3.7 https://github.com/winpython/winpython/releases.
Right now, the actual tagging and uploading of OS X and Linux wheels is pretty easy. Wget and twine make it pretty painless. The merging of incompatible PRs just before hand is just a fun side attraction.
Getting appveyor to produce a full suite of windows binaries would be a very welcome addition, as we don’t actually have all of the optional dependencies working there, nor are we actually testing on the latest Visual Studio. I appreciate @cgohlke's effort and contribution, but I’d really like to get that part automated. Bus factor of 1 and all that.
@wiredfool Fully agree. claps loudly for @cgohlke @jaraco Let's see if we can automate.
I generated a Linux wheel with this Dockerfile:
from ubuntu:xenial run apt update && apt install -y software-properties-common run apt-add-repository -y ppa:deadsnakes/ppa run apt update && apt install -y wget python3.7-dev zlib1g-dev libjpeg-dev libtiff-dev libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev libfribidi-dev tcl-dev tk-dev python3.7-tk run wget https://bootstrap.pypa.io/get-pip.py -O - | python3.7 run python3.7 -m pip wheel PillowRun thus:
$ docker build . -t pillow-wheel && docker run -v $(pwd):/out pillow-wheel sh -c "cp *.whl /out"But that wheel doesn't upload for me:
$ devpi upload Pillow-5.1.0-cp37-cp37m-linux_x86_64.whl Pillow-5.1.0-cp37-cp37m-linux_x86_64.whl: does not contain PKGINFO, skippingI'm not sure what the issue is. Maybe devpi/devpi#524.
Also, I'm not sure how compatible that will be across other flavors of Linux.
You might want to check out the pillow-wheels repo (https://github.com/python-pillow/pillow-wheels) which generates the current binaries, to avoid duplicating existing functionality.
Reacted by Jason R. CoombsHonestly, I haven't been able to wrap my head around the layers of dependencies (Pillow -> pillow-wheels -> multibuild -> multilinux). It does appear however that it's incredibly difficult to build multilinux and multi-macOS builds. I'm not planning to try to incorporate what's it pillow-wheels into this project, as it appears to be substantial enough to be its own project. I guess the best we can do is wait for Python 3.7 support to come to the upstream providers.
@jaraco Looks like 3.7 just arrived …
See python-pillow/pillow-wheels#90 for latest attempt.
python-pillow/pillow-wheels#90 is now merged and Pillow-5.2.0-cp37-cp37m-*.whl are in the Pillow Wheel Builder container.
http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/
I can upload them to PyPI tomorrow, unless someone else can do it before then.
Reacted by Jeffrey 'Alex' Clark@hugovk OK I twined them, thanks
Reacted by Hugo van Kemenade- added a commit that references this issue
on Oct 26, 2023
In #2842, we see users as early as November of last year wishing to test applications against Python 3.7. Today, I ran into the same issue.
The recommended solution was to wait for the next release of Pillow, but I don't understand why Pillow couldn't cut binary releases of the latest stable version for Python 3.7. Doing so would unblock (or facilitate) downstream applications testing on Python 3.7, so they could potentially work out any bugs before or shortly after Python 3.7 is released, rather than waiting many months after its release.
Another recommendation was to use the 3.6 wheel, but that's not a workaround that fits readily into a .travis.yml or tox.ini.
Given the fairly demanding build requirements on Pillow, it sure would be nice to make binary builds available sooner than later.
Why not cut a new maintenance release or publish 3.7 binaries for the latest stable build?