Pillow 5.1.0's included dylibs binaries stopped working on Mac El Capitan (10.11) #3068
Comments
|
That’s unintentional. |
|
Was it was caused by python-pillow/pillow-wheels#79 upgrading Xcode from version 8 to 9.2?
https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_9.x_(since_Free_On-Device_Development) |
|
That does appear to fit the problem. |
|
I'm no expert in this stuff, but it sounds like xcode9.2 simply defaults to building for 10.12, but you can still tell it to target older versions if you want. I think you can do this by setting the |
|
I’ve pushed a branch with the old Xcode, builds succeeded, so I think we’re back to a full OS X build. Look here http://a365fff413fe338398b6-1c8a9b3114517dc5fe17b7c3f8c63a43.r19.cf2.rackcdn.com/ for pillow 5.1.0 builds, anything done on 4/4 is my test, and should work as far back as the previous release. |
|
I can confirm this new .whl has me up and running with the latest Pillow now! looking at |
|
Ok, good to hear that it’s working. I think we’ll just stick with Xcode 6.4 for now, and do a 5.1.1 release shortly to fix the binaries. |
|
How about releasing a binary build with a build tag? https://github.com/MacPython/wiki/wiki/Build-Tags It's just a question of building the wheels, downloading and renaming (see script on that page) and then uploading. Oh - and deleting the previous offending wheels. |
|
I'm happy to help with the binary build ... |
|
I don't think it's a good idea to replace a known-bad version after it's been out for a while. Just bump the version. People will be fixing their builds by blacklisting the bad release: |
|
my two cents: If using build-tags lets you get the fixed 5.1.0 binaries out sooner then that seems preferable. But if 5.1.1 will get released soon anyway, then just go with that. |
|
Or do both, replace the old binary and push a new release do it works for
everyone.
…On Wed, Apr 11, 2018, 03:42 Chris Varenhorst ***@***.***> wrote:
my two cents: If using build-tags lets you get the fixed 5.1.0 binaries
out sooner then that seems preferable. But if 5.1.1 will get released soon
anyway, then just go with that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3068 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQg6x3kCLQknPVpkYsRALDYcSWdS6cVks5tnV-SgaJpZM4TF-o6>
.
|
|
I can't see the downside to fixing the binaries. OK some people may be skipping the release, but they won't be further hurt by fixed binaries. If the bad version did anything special other than crash I'd agree, but replacing crash by no-crash seems like an easy win. |
|
Please see #3089. |
|
What's the best way to get pillow-wheels building on Xcode 8? python-pillow/pillow-wheels#79 is the PR that upgraded from 8 to 9.2, because the latest multibuild was missing webp and upgrading fixed it. Upgrading to the latest multibuild was needed because rsync was missing (with but perhaps not limited to 8): python-pillow/pillow-wheels#76. |
|
To answer my own question, from upthread:
Here's a PR, it's with Xcode 6.4: python-pillow/pillow-wheels#84. |
|
Does anyone have any thoughts on what versions of macOS should be supported by pillow-wheels? We're talking about 10.11 here, so n-2? Or is it the case that we should just support as far back as we can without difficulty? |
|
I would personally say 10.10 and above but if it's easy to support I would go for all available. If osx wouldn't have died on me a few years back I'd still be running 10.10. Newer versions have always broken more than they've fixed for me |
|
I'd go for at least those supported by Apple, and further if there's no difference or not too much burden. Let's go with Xcode 6.4 now, because it's the easiest to fix with that :) Xcode 6.4 should support at least as far back as 10.10.4 Yosemite. Wikipedia gives these support statuses:
Checking pip download stats for the last 30 days, very little for pre-10.10:
(via |
|
We're advertising support for 10.6 through 10.10, e.g.: Pillow-5.1.0-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl Or, perhaps there's something subtle in the naming convention that I'm not getting. But it appears that the contents of the package don't match the naming. I'd say that in general, we should support currently shipping systems in binary, and the long tail in source. For anything but windows, pillow isn't that hard to install from source for someone who's dedicated enough to be using an out of support operating system. Either that or they can step up with some cash or labor. |
|
The naming pattern's a bit confusing I agree. It dates from the time when pip running on a Python naming itself 10.8 didn't accept a wheel with name > 10.8. That's long past now, so the name should just reflect the earliest OSX the wheel supports. What is that - on XCode 6.4? I suggest using the earliest XCode available unless there's a good reason not to. |
|
Here's the version overview by major version (the minor ones aren't too relevant here I think):
|
This change adds support for Django 2.0 and Wagtail 2.0/2.1 to this package. The README has been updated to reflect the change. A `.coveragerc` file has been added to more helpfully limit test code coverage and the test runner now dumps coverage to console for easier reviewing. These changes also include a new test fixture for easier testing of blocks. Fixes cfpb#8. To verify this change against Django 2.0 and Wagtail 2.0: 1. Create a new isolated virtualenv with Python 3.6 named `testwi`. ``` $ mkvirtualenv --no-site-packages --python=python3.6 testwi ``` 2. Install this PR into the virtualenv. Pulls in Wagtail/Django 2. This open issue (python-pillow/Pillow#3068) means that at least for now on Macs, you need to override the version of Pillow that gets pulled in from those. ```sh $ pip install git+https://github.com/chosak/wagtail-inventory.git@wagtail-django-2 $ pip install Pillow!=5.1.0 ``` 3. Create a new Wagtail project named `myproject`. ```sh $ wagtail start myproject $ cd myproject ``` 4. Edit project settings to add modeladmin, the wagtail-inventory app and its test app, along with Wagtail modeladmin, for access to a test page class and block types. ```sh diff --git a/myproject/settings/base.py b/myproject/settings/base.py index fe5d391..7e8c232 100644 --- a/myproject/settings/base.py +++ b/myproject/settings/base.py @@ -48,6 +48,8 @@ INSTALLED_APPS = [ 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', + + 'wagtail.contrib.modeladmin', + 'wagtailinventory', + 'wagtailinventory.tests.testapp', ] MIDDLEWARE = [ ``` 5. Create a database and a superuser. ```sh $ ./manage.py migrate $ ./manage.py createsuperuser ``` 6. Run the `block_inventory` command to initialize the block table. ```sh $ ./manage.py block_inventory ``` 7. Run your local server. ```sh $ ./manage.py runserver ``` 9. Login to the admin at http://localhost:8000/admin/ with the superuser you just created. Under Settings, Block Inventory you should see the two default Wagtail pages. You shouldn't see any options in the dropdown because the default pages don't include StreamField blocks. 10. Now we'll add a new page that does include StreamField blocks. In the sidebar, click Pages, Home. Click the Add Child Page button and choose one of the test page types, say "Multiple stream fields page". Add some StreamField content, then click Save Draft. 11. If you go back to Settings, Block Inventory, you'll see that the dropdown menus now include the block types that you included. Play around with adding/deleting content from the page to see how the inventory results change. Results should automatically be updated whenever the page is saved. Thanks to @alanmoo for contributing to these changes.
This change adds support for Django 2.0 and Wagtail 2.0/2.1 to this package. The README has been updated to reflect the change. A `.coveragerc` file has been added to more helpfully limit test code coverage and the test runner now dumps coverage to console for easier reviewing. These changes also include a new test fixture for easier testing of blocks. Fixes cfpb#8. To verify this change against Django 2.0 and Wagtail 2.0: 1. Create a new isolated virtualenv with Python 3.6 named `testwi`. ``` $ mkvirtualenv --no-site-packages --python=python3.6 testwi ``` 2. Install this PR into the virtualenv. Pulls in Wagtail/Django 2. This open issue (python-pillow/Pillow#3068) means that at least for now on Macs, you need to override the version of Pillow that gets pulled in from those. ```sh $ pip install git+https://github.com/chosak/wagtail-inventory.git@wagtail-django-2 $ pip install Pillow!=5.1.0 ``` 3. Create a new Wagtail project named `myproject`. ```sh $ wagtail start myproject $ cd myproject ``` 4. Edit project settings to add modeladmin, the wagtail-inventory app and its test app, along with Wagtail modeladmin, for access to a test page class and block types. ```sh diff --git a/myproject/settings/base.py b/myproject/settings/base.py index fe5d391..7e8c232 100644 --- a/myproject/settings/base.py +++ b/myproject/settings/base.py @@ -48,6 +48,8 @@ INSTALLED_APPS = [ 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', + + 'wagtail.contrib.modeladmin', + 'wagtailinventory', + 'wagtailinventory.tests.testapp', ] MIDDLEWARE = [ ``` 5. Create a database and a superuser. ```sh $ ./manage.py migrate $ ./manage.py createsuperuser ``` 6. Run the `block_inventory` command to initialize the block table. ```sh $ ./manage.py block_inventory ``` 7. Run your local server. ```sh $ ./manage.py runserver ``` 9. Login to the admin at http://localhost:8000/admin/ with the superuser you just created. Under Settings, Block Inventory you should see the two default Wagtail pages. You shouldn't see any options in the dropdown because the default pages don't include StreamField blocks. 10. Now we'll add a new page that does include StreamField blocks. In the sidebar, click Pages, Home. Click the Add Child Page button and choose one of the test page types, say "Multiple stream fields page". Add some StreamField content, then click Save Draft. 11. If you go back to Settings, Block Inventory, you'll see that the dropdown menus now include the block types that you included. Play around with adding/deleting content from the page to see how the inventory results change. Results should automatically be updated whenever the page is saved. Thanks to @alanmoo for contributing to these changes.
This version is broken, cf. python-pillow/Pillow#3068.
This version is broken, cf. python-pillow/Pillow#3068.
|
Please see issue python-pillow/pillow-wheels#96 and PR python-pillow/pillow-wheels#97 for necessary upgrades. |
|
Sorry, ignore this, noticed #6179 macos 10.14 service ended After # matplotlib 3.6.2 -> PIL 9.4.0 on macos 10.14.6 2023-01-02
# https://github.com/python-pillow/Pillow/issues/3068 ?
import sys
import platform
import PIL
print( "mac_ver :", platform.mac_ver() )
print( "python sys.version :", sys.version )
print( "PIL.__version__ :", PIL.__version__ )
print( "\nimport matplotlib" )
import matplotlib--> mac_ver : ('10.14.6', ('', '', ''), 'x86_64')
python sys.version : 3.9.12 (v3.9.12:b28265d7e6, Mar 23 2022, 18:17:11)
[Clang 6.0 (clang-600.0.57)]
PIL.__version__ : 9.4.0
import matplotlib
Traceback (most recent call last):
File "/Users/bz/etc/mac/mpl-pil-dylib.py", line 14, in <module>
import matplotlib
File "/opt/local/py/site/top/matplotlib/__init__.py", line 113, in <module>
from . import _api, _version, cbook, _docstring, rcsetup
File "/opt/local/py/site/top/matplotlib/rcsetup.py", line 27, in <module>
from matplotlib.colors import Colormap, is_color_like
File "/opt/local/py/site/top/matplotlib/colors.py", line 51, in <module>
from PIL import Image
File "/opt/local/py/site/top/PIL/Image.py", line 103, in <module>
from . import _imaging as core
ImportError: dlopen(/opt/local/py/site/top/PIL/_imaging.cpython-39-darwin.so, 2): Library not loaded: @loader_path/libXdmcp.6.dylib
Referenced from: /opt/local/py/site/top/PIL/.dylibs/libxcb.1.1.0.dylib
Reason: no suitable image found. Did find:
/opt/local/py/site/top/PIL/.dylibs/libXdmcp.6.dylib: cannot load 'libXdmcp.6.dylib' (load command 0x80000034 is unknown)
/opt/local/py/site/top/PIL/.dylibs/libXdmcp.6.dylib: cannot load 'libXdmcp.6.dylib' (load command 0x80000034 is unknown)Xcode, otool -- |
Since you already know how to pin to the previous version's wheel, I don't know what you're after. You'd like to be able to run the same command on macOS 10.14 and install Pillow 9.3, and on later macOS versions, install the latest Pillow? |
|
@radarhere, yes, exactly that: install the latest Pillow that works on my macOS. |
|
I'm guessing that the change was because python-pillow/pillow-wheels#350 updated libXau to 1.0.11. Homebrew removed support for 10.15 when making that update - Homebrew/homebrew-core@712726c I can't even test macOS 10.14 on GitHub Actions to investigate further - https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources If you want to confirm my theory, you can test the wheels from https://github.com/radarhere/pillow-wheels/actions/runs/3825868768 - https://github.com/radarhere/pillow-wheels/suites/10148738168/artifacts/495813662. They are Pillow 9.4.0, but with libXau 1.0.10. I don't think there's a way to adjust our wheels to work on macOS 10.14 without either removing or downgrading the dependency. You might be interested in building Pillow from source instead - |
|
More specifically, you can |
|
I've created python-pillow/pillow-wheels#357 as a possible solution to this. It downgrades the dependency for macOS < 11 and unfortunately 64-bit macOS >= 11 Python < 3.10, but otherwise keeps the latest version. |
|
@radarhere, thanks for taking the time to look at this; I should've recognized the problem (10.14) sooner, my fault.
Any idea how other people e.g. conda handle this ? |
|
The wheel you would have been downloading is Pillow-9.4.0-cp39-cp39-macosx_10_10_x86_64.whl. In my PR, I've found that the end of the wheel name can be macosx_11_0_x86_64.whl, meaning that the wheel would only be used on macOS >= 11, but from what I can see, that ending is only supported for Python 3.10 and 3.11. This is making use of PEP 425. |
|
python-pillow/pillow-wheels#358 has been merged. Future Pillow wheels should work on macOS 10.14 again. |
|
I've uploaded new Pillow 9.4.0 wheels. Installation should now work. |
What did you do?
Upgraded pillow from 5.0 to 5.1
What did you expect to happen?
For Pillow to keep working, or at least for the Pillow 5.1.0 change log to report that only 10.12+ is supported.
What actually happened?
When trying to use pillow through the python
captchapackage, I got this error:What versions of Pillow and Python are you using?
Pillow 5.1.0 has the problem. Running Python 3.6.5.
To reproduce this problem try testing Pillow on a 10.11 system. Specifically, just import PIL.image to trigger this.
Installing
pillow==5.0.0fixed the issue.Did you intentionally drop 10.11 support? If not it'd be great for this to keep working! Probably just means rebuilding the dylibs with 10.11 support.
If you meant to drop support than just clearer messaging around this would be helpful. (changelog, explicit version check and error message)
The text was updated successfully, but these errors were encountered: