Comments (19)
Oh! We never used to provide ARM64 OSX wheels!
https://pypi.org/project/aggdraw/1.3.16/#files
You've been building from source before 1.3.17. Add --no-binary
to your pip install aggdraw
command (pip install --no-binary aggdraw
) and it should be a short term workaround.
from aggdraw.
Oops, got formatting wrong on my previous comment, updated it now.
from aggdraw.
Thanks for letting me know.
This is a difficult one to fix and decide what the right solution is. I don't think I ever intentionally installed freetype. You can see in the CI config I install freetype for linux, but have never done anything for osx or Windows. It looks like cibuildwheel uses pipx
to build in different Python environments but I'm not exactly sure why it can't find a version of freetype that is installed on the system.
If I go to the work of installing freetype on the osx builds then I want to be sure it is as compatible as it used to be.
In your tests did you only change the version of aggdraw? Or did the rest of your environment change too?
Do you have suggestions for where I should install freetype from?
from aggdraw.
I see in the latest build log that it finds:
Repairing wheel...
+ delocate-wheel --require-archs x86_64 -w /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-x74ze_f6/cp39-macosx_x86_64/repaired_wheel -v /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-x74ze_f6/cp39-macosx_x86_64/built_wheel/aggdraw-1.3.18-cp39-cp39-macosx_10_9_x86_64.whl
INFO:delocate.delocating:Copying library /usr/local/Cellar/freetype/2.13.2/lib/libfreetype.6.dylib to aggdraw.dylibs/libfreetype.6.dylib
INFO:delocate.delocating:Copying library /usr/local/Cellar/libpng/1.6.40/lib/libpng16.16.dylib to aggdraw.dylibs/libpng16.16.dylib
INFO:delocate.delocating:Modifying install name in aggdraw.dylibs/libfreetype.6.dylib from /usr/local/opt/libpng/lib/libpng16.16.dylib to @loader_path/libpng16.16.dylib
INFO:delocate.delocating:Modifying install name in aggdraw.cpython-39-darwin.so from /usr/local/opt/freetype/lib/libfreetype.6.dylib to @loader_path/aggdraw.dylibs/libfreetype.6.dylib
Fixing: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-x74ze_f6/cp39-macosx_x86_64/built_wheel/aggdraw-1.3.18-cp39-cp39-macosx_10_9_x86_64.whl
Copied to package .dylibs directory:
/usr/local/Cellar/freetype/2.13.2/lib/libfreetype.6.dylib
/usr/local/Cellar/libpng/1.6.40/lib/libpng16.16.dylib
This suggests that the wheels should have freetype in them.
from aggdraw.
Hm it looks like the x86 osx wheels have the libraries, but not the ARM ones. 😕
from aggdraw.
From what I can tell I could install a separate instance of homebrew and install packages there. I'm not sure I want to go down that road, but hopefully someone has a better idea and can comment here.
from aggdraw.
David,
You are right, until 1.3.16 the installation was from source. I did not realize that. So the temporary solution from #93 seem the right approach for now.
On my Mac pip seems to pick up libfreetype from /opt/homebrew
.
I will try to better understand the CI system and freetype on macOS. Note sure yet what is the first-class solution to building/providing it in such context.
from aggdraw.
I'm not familiar enough with how reliable wheels are when they bundle versions of shared libraries internally. I, for some reason, thought it would just require the user have the library installed but it seems they are bundled inside the wheel. So I'm not sure if that makes things better or worse or easier or riskier.
from aggdraw.
After some thinking:
-
Including libfreetype and libpng dynamic libraries in the wheel seems to be the correct thing to do. Many others do the same, e.g. numpy and scipy include libopenblas and libquadmath.
-
The
delocate-wheel
tool takes care of copying the dynamic libraries and relinking the binaries to refer to new locations. It works as advertised. For thex86_64
wheel it copies over the appropriate libraries from/usr/local/Cellar
on the macOS runner. The issue is that it cannot do the same for thearm64
wheel because the libs in/usr/local/Cellar
are for forx86_64
only. -
Do we know whether the macOS runner executing the GitHub action has an Intel (
x86_64
) or Apple Silicon (arm64
) CPU? The easy way would be to have anarm64
macOS runner to build thearm64
wheels, similarly how it is done forx86_64
. -
Alternatively, as you mentioned, one can try installing
arm64
homebrew onx86_64
system, like discussed here.
Once the macOS runner has the arm64
freetype and libpng installed, the arm64
wheels should build correctly.
from aggdraw.
Yes, this is the conclusion I was coming to also. Github does not currently provide arm64 runners. All non-native wheel builds are emulated (arm64 running on x86_64). So yeah the options are either no wheels for arm64 or go through the complicate process of installing an arm version of homebrew to get access to the arm64 freetype.
from aggdraw.
I am not familiar with the Github infrastructure.
Does Github provide free or very-low cost runners?
Isn't this announcement about an arm64 native macOS runner? This one is definitely not free though.
from aggdraw.
That looks arm-based, yes. Definitely not free. The other option is to use a different CI provider that does provide arm runners, but I really don't want to maintain two CI services for a project like this.
from aggdraw.
Let me know if you need any help with figuring this out, I have access to both arm64 and x86_64 Macs.
from aggdraw.
So I could either make a new release that doesn't include the ARM64 wheels or I could remove the ARM64 wheels for the existing release. Opinions?
I do not plan on doing the fancy homebrew stuff to get freetype for ARM64 and/or other architectures. If someone wants to do that and try that out, go for it. I'd be curious what it looks like in github actions.
from aggdraw.
So I could either make a new release that doesn't include the ARM64 wheels or I could remove the ARM64 wheels for the existing release. Opinions?
For users with newish Macs that come with M1, M2, or M3 CPUs, which is an ever growing number, there is no difference between these two options. Either way they have to have freetype installed and xcode tools installed in order to install aggdraw.
I do not plan on doing the fancy homebrew stuff to get freetype for ARM64 and/or other architectures. If someone wants to do that and try that out, go for it. I'd be curious what it looks like in github actions.
I will look into this.
Several important goals that I see:
- keeping all wheels well encapsulated (contain what they need)
- keeping all wheels similar (all contains the same libs)
- not requiring users to install a compiler chain to install aggdraw
from aggdraw.
Agreed. And also: keeping maintenance burden to a minimum 😉
from aggdraw.
Please see PR #94 with fix for this issue.
from aggdraw.
I made a release with #94's changes. @devbanu please let me know if this fixed things for you.
from aggdraw.
Yep, tested, and it works!
from aggdraw.
Related Issues (20)
- antigrain.com is squatted HOT 6
- multline text not supported HOT 1
- Line anti-aliasing issues due to missing sRGB mishandling HOT 5
- Resolve differences after agg 2.2 and agg 2.4 migration HOT 3
- aggdraw.Draw, aggdraw.Pen, aggdraw.Brush, etc... are not extendable (apparently) HOT 1
- Cannot install on Windows HOT 2
- MNT: Stop using ci-helpers in appveyor.yml HOT 1
- documentation has left the chat. HOT 1
- Latest Documentation? HOT 7
- pip install results in error Windows 10 21H1 HOT 4
- aggdraw does not some to be able to find fonts when installed in a venv HOT 3
- No arc symbols? HOT 1
- is there a way to draw squircle (rectangle with rounded edges) ? HOT 4
- Add support to release linux aarch64 wheels HOT 3
- PyPy3.8 support HOT 6
- Windows binaries are missing for aggdraw 1.3.13 on pypi.org HOT 4
- The value in the coordinates list cannot exceed 32767. HOT 1
- Diferences between pip version and source-compiled version HOT 4
- Misleading information in the document HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aggdraw.