[Pyobjc-dev] Moving PyObjC and py2app forward

[Ronald O. <ron...@ma...>]

Hi,

’Tis the time to be contemplative, and I’ve been thinking a bit about PyObjC, py2app: what I’d like to do with them, and how much time I have to work on them.  Things don’t quite add up because there’s a lot more that I’d like to do than I expect to be able to do in any reasonable timeframe.

In no particular order (and far from complete):

Finish work to add metadata for APIs introduced in OSX 10.10 and 10.9 (update existing framework wrappers and add new ones where appropriate)

It should be pretty straightforward to add metadata now that objective.metadata is based on libclang (thanks to James Ranking). It is however still a relatively large amount of work because it is necessary to manually check which APIs require manual additions to the metadata, and because I prefer to add unittests for the framework wrappers because those have caught a fair amount of problems in the past.

Python 3.4 adds an “asyncio” library (with backports on PyPI). It would be useful to add a pluggable event loop that integrates with Cocoa’s runloop (NSRunloop and CFRunloop), and furthermore it would be interesting to see if the tasks and coroutines from asyncio can be used to simplify Cocoa code: any Cocoa code with a “completionHandler” argument block might give nicer python code when used from a coroutine.

That is, instead of something like:

    def onCompletion(result): 
         # …

    anObject.runTaskWithCompletionHandler(onCompletion)

you’d get something like:

    result = anObject.runTask()
    # …

There needs to be a significant example of how to write a GUI without using XIB files. 
To expand on the previous item: there needs to be a non-trivial example for writing a GUI with PyObjC that addresses issues one commonly runs into with writing code (aggressivly catch python exceptions before they cause problems in Cocoa, …).  This can be used to enhance PyObjC itself: instead of adding work-arounds for odd behavior try to address the root cause.

It’s time to try to refactor py2app into a library that does the work and a setuptools extension for the API. There are two reasons for that: this gives us a fighting chance to add useful unittests (py2app’s tests currently are primarily slow integration tests), and secondly this would make it a lot easier to design a modern interface that doesn’t rely on setuptools (using a declarative configuration file, …)

py2app currently doesn’t support code signing, setuptools metadata, adding entire eggs/wheels and more. All of those are more and more necessary to ship the output of py2app outside of a controlled environment and AFAIK a number of py2app users work around the lack of those features by adding pre- and post-process scripting around py2app.

Both py2app and PyObjC need significant work on their documentation. The documentation for py2app is minimal enough to make it effectively non-existing.

PyObjC and py2app need some form of CI, especially for supporting platforms and libraries I don’t use regularly myself (for example OSX 10.6 support in PyObjC and support for PyQt in py2app). Something like Jenkins or buildbot could work, but setting up the infrastructure requires effort. I currently have to manually test, and due to lack of time I rarely run on older OSX releases and that seems to have resulted in breakage (for example issue #100 on PyObjC’s tracker).

I’m not sure how to make serious progress with my current load (both work and privately).  Does anyone have experience with crowd-funding for open-source work? 

Ronald