Gregory Neagle
unread,Apr 9, 2021, 6:32:50 PM4/9/21Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to munki-dev
In the Munki5dev branch, I've updated the version of Python to 3.9.4.
PyObjC 7.1 was released at the end of December 2020, but it appears Ronald O uploaded wheels containing only x86_64 libraries. So I (so far) have not updated the version of PyObjC past 7.0.1.
I did ping Ronald O once or twice about the PyObjC 7.1 wheels, but he's made no changes. It's free software from a volunteer, so he owes us exactly nothing and I don't plan to bug him any more.
But: if we set --no-binary :all: in the py3_requirements.txt, we can build a Universal2 Python 3.9.4 framework containing PyObjC 7.1. The problem is it takes a long time, since it has to build every PyObjC module from source. Personally, that's not a huge issue for me, since I don't build new versions of the Python framework very often. But there are some people who have set up Continuous Integration-style jobs to build Munki packages daily or with every git push or whatever and have expressed to me concern about the time taken here.
My inclination is to say "thems the breaks right now" and just deal with the slow build times for now.
If someone wants to work on some optimization strategies, here are a few I can think of:
1) Don't always build a new Python framework; build it once and cache it for future pkg builds until a new version needs to be built
2) Do some analysis and instead of including all of PyObjC, figure out what subset is actually needed/required
3) Volunteer to help Ronald O with PyObjC maintenance tasks and help him get Universal2 wheels uploaded to PyPi.
I'm sure there are other possibilities.
-Greg