On 12/12/09 2:33 PM, has wrote:
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.

Exactly what I'm doing--with bundlebuilder.
>
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.


A fine project to take on if a) you use Xcode and b) you're doing PyObjC development. I am doing neither, so this doesn't interest me.

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.


We disagree about bundlebuilder, but Apple's decision to deprecate Carbon made removing those bits from the standard library the only sane decision. None of that stuff works with a 64-bit build of 2.6, that's for sure.

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to