Provide Tcl command for manipulating plists

[ryandesign (Ryan Carsten Schmidt)]

plist files are everywhere on macOS. Two specific plists that MacPorts needs to deal with frequently are launchd plists (in portstartupitem.tcl) and Info plists (in the app 1.0 portgroup). In both cases, the plists are constructed manually with string concatenation. This is cumbersome and error prone. In addition, some ports desire to augment the plists that MacPorts has generated and currently have to resort to convoluted string manipulation to do this, or forgo the MacPorts-generated plists entirely and provide their own replacement.

MacPorts should provide a Tcl command for manipulating plists. This could be a simple wrapper that just calls an existing executable. Two candidate executables are PlistBuddy and plutil. Some ports already use one; some already use the other.

PlistBuddy has the advantage that it exists on all versions of macOS that MacPorts runs on and its syntax allows complex plist modifications. It is at /usr/libexec/PlistBuddy on 10.5 and later. It is not installed in a standard location on 10.4 but it is present in several installer receipts and MacPorts could find it there when needed.

plutil is installed at /usr/bin/plutil since 10.2 but the -insert, -replace and -remove commands that would be most interesting to us didn't appear until 10.9.

Another option is that MacPorts could implement its own plist modification functionality directly in Tcl. This would avoid the need to call out to another executable, which might be a significant performance gain if we consider that the command may need to be invoked dozens of times to build up a single plist, and would avoid the problems of either locating PlistBuddy on 10.4 or dealing with plutil's deficiencies prior to 10.9. To avoid having to write the plist to disk between every invocation, we might even consider an API where a plist could be read into memory, then successive commands could modify that in-memory representation, and finally it could be written out again.

Whatever we implement, the existing code that creates plists could be rewritten to use the new method. This might make that code easier to read and modify in the future.

Providing a generic plist modification facility might reduce the need to offer an ever growing set of options specific to either the launchd or Info plists.