Christopher Barker wrote: > It's open-source, it's only going to get done if someone that needs it rolls > up his/her sleeves and does it -- which may mean learning more about the > nitty gritty details of OS-X.
Yep. If you want something done right, sometimes you just gotta step up and do it yourself. It's that or large cash bribes to get someone else to do it; take your pick. > My suggestion to Charles, and Kevin, (and me!) is to try to find some time to > dig into py2app -- I think once you grok the code structure, you can probably > find the source of the errors, and then, if you can't figure out a solution, > Ronald or Ned (or??) might be able to help out, without them having to do all > the work -- i.e. use the experts only for the part where their expertise is > critical. I'd go further, and suggest pulling py2app to pieces. Creating an executable stub is a separate task to bundling project files is a separate task to locating and bundling third-party module dependencies is a separate task to bundling a Python framework (full or stripped). Some of these parts have more intrinsic value than others (e.g. identifying module dependencies), particularly as they can be used cross-platform and so will be easier to muster maintainers. Rather than revive the moribund bundlebuilder, put the time you'd spend on that into bringing the Xcode-Python templates up to scratch. The executable stub is a piece of crap that imports the first Python framework it finds, as opposed to the version you built with; fixing this should not be too difficult if you know some C/ObjC (dynamically binding framework functions is not that hard - I've done it myself - and you can borrow the code from py2app). Once you've got Xcode building Python-based .app bundles that don't suck, you can look at providing dependency bundling as an extra build phase. Personally, I like py2app and I'm not a huge fan of Xcode for Python development, but the first rule of sustainable OSS development has to be: when you have limited time, knowledge and manpower at your disposal, invest it on functionality that can't be leveraged from elsewhere. Xcode is not ideal, but it's good enough. In addition, Xcode's privileged position in OS X development makes it the first stopping point for newcomers to Python+PyObjC development, so targeting it will help market Python for Mac application development and strengthen the community as a whole. HTH has p.s. Re. the original subject line, kicking bundlebuilder and the rest of the decaying/decayed Mac-specific libraries out of Python's stdlib was completely the right decision for Python's overall health. -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
