Munki's PyObjC included framework bindings

25 views
Skip to first unread message

Greg Neagle

unread,
May 5, 2022, 12:25:06 PM5/5/22
to munki-dev, 'Gregory Neagle' via munki-discuss
While working on the 5.7 Beta 2 release, I had to explicitly list all of the PyObjC modules to be installed to avoid installing one that causes problems.


There are a _lot_ of PyObjC bindings for things Munki does not need.

I looked though the Munki code, and determined only these PyObjC bindings are actually needed:

AppKit
CoreFoundation
CFNetwork
Foundation
LaunchServices
Quartz
Security
SystemConfiguration

I did an experimental build that had only these pyobjc modules in the requirements.txt:

pyobjc-core==8.5
pyobjc-framework-CFNetwork==8.5
pyobjc-framework-LaunchServices==8.5
pyobjc-framework-Quartz==8.5
pyobjc-framework-Security==8.5
pyobjc-framework-SystemConfiguration==8.5

(AppKit, CoreFoundation, and Foundation are included in “pyobjc-core”)

It built much much faster (which should not be surprising), and the resulting package is 2MB smaller (was 52MB, now 50MB, so not a _huge_ space savings). The installed Python.framework shrinks from 153M to 135M.

But this change is not without risks. Any admin that is using Munki’s python to run other Python scripts might be using PyObjC bindings that Munki itself does not need/use. If those bindings are removed, those scripts will break. 

I’m not yet sure about the benefits/risk ratio for this change, but I’m leaning towards making the change: having to build less not only makes the build faster, but also more reliable as there is less code to fail at build time.

-Greg

Per Olofsson

unread,
May 6, 2022, 3:26:55 AM5/6/22
to munk...@googlegroups.com
5 maj 2022 kl. 18:25 skrev 'Greg Neagle' via munki-dev <munk...@googlegroups.com>:
>
> But this change is not without risks. Any admin that is using Munki’s python to run other Python scripts might be using PyObjC bindings that Munki itself does not need/use. If those bindings are removed, those scripts will break.
>
> I’m not yet sure about the benefits/risk ratio for this change, but I’m leaning towards making the change: having to build less not only makes the build faster, but also more reliable as there is less code to fail at build time.


We're using munki-python a fair bit, for things like conditions and package scripts, and having a fully kitted out PyObjC is quite comforting. But like you I struggled recently to build all the modules when working on MunkiReport, so I understand that there's a burden of maintaining it. I looked through our deployed scripts and I don't think we're currently using anything other than the modules you listed, but I would be sad if at least OpenDirectory didn't make the cut.

--
Per Olofsson, IT-service, University of Gothenburg

Greg Neagle

unread,
May 6, 2022, 11:54:44 AM5/6/22
to munki-dev
Including OpenDirectory seems a fair ask, and I’d be open to including a few more that would be of use for admin scripts. But there’s a bunch of bindings like "CallKit”, “CoreMIDI”, “DVDPlayback” and “LatentSemanticMapping” (and dozens of others) that seem totally pointless to have present. This whole area of exploration was triggered when I had problems installing PyObjC 8.5 because “ScreenCaptureKit” would not compile…

-Greg

MiqViq

unread,
May 7, 2022, 8:51:08 AM5/7/22
to munki-dev
Hi,

I do not know if this will change anything but there is a new PyObjC 8.6 which has some fixes, does not mention ScreenCaptureKit:


-MiqViq

Reply all
Reply to author
Forward
0 new messages