From nicholas.cole at gmail.com  Tue Jun  3 10:59:21 2014
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Tue, 3 Jun 2014 09:59:21 +0100
Subject: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
In-Reply-To: <700039AB-02C9-4033-87D2-6326E06C37D8@mac.com>
References: <245FA66F-1231-4480-9FE1-956946A214D4@mac.com>
 <700039AB-02C9-4033-87D2-6326E06C37D8@mac.com>
Message-ID: <CAAu18heQOPaE=uE8vvmvunivj7f2rcw30H_Nb_QJE3JJuu1xtw@mail.gmail.com>

Hi Roland,

Could we all have an update on development plans?  Do you think PyObjC
is going to work nicely with OS X 10.10?

N.

On Mon, Aug 26, 2013 at 12:42 PM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> On 4 Jul, 2013, at 17:08, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>
>> My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.
>
> That seems to be overly optimistic on my part, I've done almost no work on PyObjC since my previous mail due to lack of time.
>
> Ronald
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

From amorris at mistermorris.com  Tue Jun  3 12:40:37 2014
From: amorris at mistermorris.com (Adam Morris)
Date: Tue, 3 Jun 2014 18:40:37 +0800
Subject: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
In-Reply-To: <CAAu18heQOPaE=uE8vvmvunivj7f2rcw30H_Nb_QJE3JJuu1xtw@mail.gmail.com>
References: <245FA66F-1231-4480-9FE1-956946A214D4@mac.com>
 <700039AB-02C9-4033-87D2-6326E06C37D8@mac.com>
 <CAAu18heQOPaE=uE8vvmvunivj7f2rcw30H_Nb_QJE3JJuu1xtw@mail.gmail.com>
Message-ID: <A01DD499-FA84-4B9A-8DCA-0818D2D2EFB7@mistermorris.com>

I'm also very eager to hear an update, but PyObjC is going to be competing with Swift now!

> On Jun 3, 2014, at 4:59 PM, Nicholas Cole <nicholas.cole at gmail.com> wrote:
> 
> Hi Roland,
> 
> Could we all have an update on development plans?  Do you think PyObjC
> is going to work nicely with OS X 10.10?
> 
> N.
> 
> On Mon, Aug 26, 2013 at 12:42 PM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>> 
>>> On 4 Jul, 2013, at 17:08, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>> 
>>> My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.
>> 
>> That seems to be overly optimistic on my part, I've done almost no work on PyObjC since my previous mail due to lack of time.
>> 
>> Ronald
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

From ronaldoussoren at mac.com  Tue Jun  3 13:06:59 2014
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Jun 2014 11:06:59 +0000 (GMT)
Subject: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
Message-ID: <524a6c53-cba7-4584-abd5-4dda6b07fb74@me.com>

Hi,

I'm continuing to work on PyObjC and hope to push a release to PyPI next weekend. ?Development is going very slowly at the moment due to lack of time on my end, I'm doing all development in my spare time and that's filled with other stuff at the moment (and has been for a while).

I have no reason to assume that PyObjC won't work on 10.10, with some luck I'll "only" have to update the metadata to support new APIs. That's annoying work, but not very hard.

From what I've seen so far, and that's only a 5 minute glance at the public documentation, Swift will be a competing product as an easy scripting-like way to build applications. That's no reason to stop work on PyObjC though, I'm using PyObjC to write GUIs for applications where most of the code is written in Python and is using cross-platform Python code. Swift changes nothing for that use case w.r.t. Objective-C.

Swift might provide both opportunities and challenges in the future: Swift method names seem to be more like classic C- (and Python-) style names and not segmented names as used by Objective-C. As Swift can use existing ObjC libraries there might be some kind of translation table for method names, and if that exists this could be used by PyObjC as well to provide nicer names in Python code (instead of the ugly names we have to use now).

A possible challenge is the runtime model of Swift: I have no idea if Swift has, or will have, runtime introspection possibilities that could be used in the future to expose Swift libraries to Python code. ?

Ronald

On Jun 03, 2014, at 12:40 PM, Adam Morris <amorris at mistermorris.com> wrote:

I'm also very eager to hear an update, but PyObjC is going to be competing with Swift now!

 ? ? ? ?> On Jun 3, 2014, at 4:59 PM, Nicholas Cole <nicholas.cole at gmail.com ? ?> wrote:
 ? ? ? ?> 
 ? ? ? ?> Hi Roland,
 ? ? ? ?> 
 ? ? ? ?> Could we all have an update on development plans? Do you think PyObjC
 ? ? ? ?> is going to work nicely with OS X 10.10?
 ? ? ? ?> 
 ? ? ? ?> N.
 ? ? ? ?> 
 ? ? ? ?> On Mon, Aug 26, 2013 at 12:42 PM, Ronald Oussoren
 ? ? ? ?> <ronaldoussoren at mac.com ?> wrote:
 ? ? ? ?> ? ? ? ?> 
 ? ? ? ?> ? ? ? ?> ? ? ? ?> On 4 Jul, 2013, at 17:08, Ronald Oussoren <ronaldoussoren at mac.com ? ? ?> wrote:
 ? ? ? ?> ? ? ? ?> ? ? ? ?> 
 ? ? ? ?> ? ? ? ?> ? ? ? ?> My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.
 ? ? ? ?> ? ? ? ?> 
 ? ? ? ?> ? ? ? ?> That seems to be overly optimistic on my part, I've done almost no work on PyObjC since my previous mail due to lack of time.
 ? ? ? ?> ? ? ? ?> 
 ? ? ? ?> ? ? ? ?> Ronald
 ? ? ? ?> ? ? ? ?> _______________________________________________
 ? ? ? ?> ? ? ? ?> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
 ? ? ? ?> ? ? ? ?> http://mail.python.org/mailman/listinfo/pythonmac-sig
 ? ? ? ?> ? ? ? ?> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
 ? ? ? ?> _______________________________________________
 ? ? ? ?> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
 ? ? ? ?> https://mail.python.org/mailman/listinfo/pythonmac-sig
 ? ? ? ?> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20140603/710fc5f2/attachment.html>

From nicholas.cole at gmail.com  Tue Jun  3 15:00:11 2014
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Tue, 3 Jun 2014 14:00:11 +0100
Subject: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
In-Reply-To: <524a6c53-cba7-4584-abd5-4dda6b07fb74@me.com>
References: <524a6c53-cba7-4584-abd5-4dda6b07fb74@me.com>
Message-ID: <CAAu18hd9y_mh5NFnDpSkaxr48uzrOhn3-xhx=E7zK_xH01we6A@mail.gmail.com>

On Tue, Jun 3, 2014 at 12:06 PM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> From what I've seen so far, and that's only a 5 minute glance at the public
> documentation, Swift will be a competing product as an easy scripting-like
> way to build applications. That's no reason to stop work on PyObjC though,
> I'm using PyObjC to write GUIs for applications where most of the code is
> written in Python and is using cross-platform Python code. Swift changes
> nothing for that use case w.r.t. Objective-C.

I'm very glad to hear you say this.  I have downloaded the
documentation for Swift, and read it.  It looks like a huge
improvement on Objective-C, but I would have been very sad indeed if
it had led you to abandon PyObjC.  In fact, if you are right that
there is now some kind of translation table that could make PyObjC
method names even better, that would be really brilliant.

N.

From ronaldoussoren at mac.com  Tue Jun  3 21:58:46 2014
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Jun 2014 21:58:46 +0200
Subject: [Pythonmac-SIG] [Pyobjc-dev]   Towards PyObjC 3.0
In-Reply-To: <CAAu18hd9y_mh5NFnDpSkaxr48uzrOhn3-xhx=E7zK_xH01we6A@mail.gmail.com>
References: <524a6c53-cba7-4584-abd5-4dda6b07fb74@me.com>
 <CAAu18hd9y_mh5NFnDpSkaxr48uzrOhn3-xhx=E7zK_xH01we6A@mail.gmail.com>
Message-ID: <448D7D13-3F82-4B4E-8C08-F574B4AD7786@mac.com>


On 03 Jun 2014, at 15:00, Nicholas Cole <nicholas.cole at gmail.com> wrote:

>   In fact, if you are right that
> there is now some kind of translation table that could make PyObjC
> method names even better, that would be really brilliant.

I was too optimistic about that, looking at the section about methods in the Swift book (page 339 and onwards) Swift by default treats the second and later arguments of a method as function parameters with ?external names? (see page 221 for a definition of that), which similar to required keyword parameters in Python 3, that is:

       func splitBy(separator: String, maxCount: Int) -> Array { ?}

as a method on a String-like class is more or less similar to the following Python definition:

       def splitBy(separator, *, maxCount): ?

And that cleanly translates into:

     -(NSArray) splitBySeparator:(NSString*)separator maxCount:(NSInteger)maxCount;

More importantly, it should generally be trivial to derive the Swift definition from the Objective-C one. 

I?ve in the past looked at using keyword arguments (basically a **kwds argument) to do something similar for PyObjC, but that doesn?t work in general because the order of keyword arguments in a call isn?t preserved in ?kwds?, and that makes it expensive to derive Objective-C selector from the keyword dictionary (and in theory there might be two methods with the same segments in a different order). 

There?s been some talk about using an OrderedDict for the dictionary that?s used for **kwds on python-list, but I don?t recall the result of that discussion and even that did work out that would at best turn up in Python 3.5.

BTW. It might be possible to use a similar algorithm to derive Pythonic names for Objective-C selectors, but that would either require eagerly scanning the methods in an class, or doing the work up front and storing the result in metadata. Neither option is particularly appealing.  But you never know, maybe Swift inspires me to come up with a smart solution to the naming problem ;-)

Ronald

P.S. This is still without having read the Swift documentation.

From hengist.podd at virgin.net  Thu Jun  5 22:34:49 2014
From: hengist.podd at virgin.net (has)
Date: Thu, 05 Jun 2014 21:34:49 +0100
Subject: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
Message-ID: <5390D469.5000302@virgin.net>

Ronald Oussoren wrote:

 >> In fact, if you are right that
 >> there is now some kind of translation table that could make PyObjC
 >> method names even better, that would be really brilliant.
 >
 >I was too optimistic about that, looking at the section about methods 
in the Swift book (page 339 and onwards) Swift by default treats the 
second and later arguments of a method as function parameters with 
?external names? (see page 221 for a definition of that), which similar 
to required keyword parameters in Python 3, that is:
 >
 > func splitBy(separator: String, maxCount: Int) -> Array { ?}
 >
 >as a method on a String-like class is more or less similar to the 
following Python definition:
 >
 > def splitBy(separator, *, maxCount): ?
 >
 >And that cleanly translates into:
 >
 > -(NSArray) splitBySeparator:(NSString*)separator 
maxCount:(NSInteger)maxCount;

Yep, it's not runtime translation, its syntactic swizzling being done in 
the parser. MacRuby did [1] the same thing IIRC, allowing Ruby users to 
write methods using familiar Ruby method name + keyword args syntax, but 
obviously what looked like the method's name was only part of it and the 
'keyword' args were 100% positional and order-sensitive: the parser just 
stripped out the 'keywords' and reassembled the real ObjC signature.

It also meant, of course, that you could safely have several methods 
with identical-looking 'names' in the same class, even though Ruby 
doesn't support method overloading, because they weren't really 
identical names at all and therefore didn't actually mask each other. 
That alone should rule out a translation table approach, since Python 
would only give you the last splitBy(...) method in your class; every 
other splitBy(...) would be masked by it, regardless of what their 
selector names are.

Whether you could dive into Python's lexer/tokenizer/parser/AST and do 
the same sort of swizzling as MR there, I don't know.

And I really wouldn't like to say if it'd be a wise choice or not: the 
current syntax is ugly, but you can throw rocks at it and it's still 
guaranteed to work, whereas once you start mucking with something as 
complex and knotty as Python syntax, who knows what you might step on?

HTH

has


From brendan.simon at etrix.com.au  Sat Jun  7 15:31:34 2014
From: brendan.simon at etrix.com.au (Brendan Simon (eTRIX))
Date: Sat, 07 Jun 2014 23:31:34 +1000
Subject: [Pythonmac-SIG] Code signing py2app generated apps
Message-ID: <53931436.2090601@etrix.com.au>

Is there anything special one needs to do to sign py2app generated apps ?

I've tried:  codesign -s <certificate-identifier> <path-to-my-app>

but I when verifying it with "codesign -v" I get:

    src/dist/SureAnalysis.app: Unknown format in import.
    In architecture: i386

The certificate is a .p12 file that was imported with KeyChain.app to
the System destination keychain.

I've read that all binaries and frameworks need to be signed.  Is there
an easy way of doing that ?  Is there a tool to determine which files
need to be signed ?

Thanks,
Brendan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20140607/439d8c05/attachment.html>

From kw at codebykevin.com  Sat Jun  7 18:29:34 2014
From: kw at codebykevin.com (Kevin Walzer)
Date: Sat, 07 Jun 2014 12:29:34 -0400
Subject: [Pythonmac-SIG] Code signing py2app generated apps
In-Reply-To: <53931436.2090601@etrix.com.au>
References: <53931436.2090601@etrix.com.au>
Message-ID: <53933DEE.9010305@codebykevin.com>

On 6/7/14, 9:31 AM, Brendan Simon (eTRIX) wrote:
> Is there anything special one needs to do to sign py2app generated apps ?
>
> I've tried:  codesign -s <certificate-identifier> <path-to-my-app>
>
> but I when verifying it with "codesign -v" I get:
>
>      src/dist/SureAnalysis.app: Unknown format in import.
>      In architecture: i386
>
> The certificate is a .p12 file that was imported with KeyChain.app to
> the System destination keychain.
>

This works for me:

codesign --deep --signature-size 9400  -f -s "Developer ID Application: 
Kevin Walzer"  cbk/QuickWho.app

I use cx_freeze in this app, not py2app, but this also worked for me 
with py2app.

--Kevin


-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

From a.paeffgen at software-geeks.de  Sun Jun  8 10:01:45 2014
From: a.paeffgen at software-geeks.de (apaeffgen)
Date: Sun, 8 Jun 2014 10:01:45 +0200
Subject: [Pythonmac-SIG] py2app 0.8.1 with python3.4 + pyqt5 crashes the app
Message-ID: <ln1597$cqc$1@ger.gmane.org>

Hi All,

Starting the app inside the bundle on the command line works fine with 
some menu glitches, but clicking on the Application Icon the app 
crashes. The crash report is listet below:

Process:         Opml_Converter [53618]
Path:            /Users/USER/*/Opml_Converter.app/Contents/MacOS/Opml_Converter
Identifier:      org.pythonmac.unspecified.Opml_Converter
Responsible:     Opml_Converter [53618]
27  org.pythonmac.unspecified.Opml_Converter	0x000000010000275b 
0x100000000 + 10075
28  org.pythonmac.unspecified.Opml_Converter	0x000000010000117a main + 650
29  org.pythonmac.unspecified.Opml_Converter	0x0000000100000be4 start + 52
       0x100000000 -        0x100009fff 
+org.pythonmac.unspecified.Opml_Converter (0.0.0 - 0.0.0) 
<FFD751CA-37B6-3FAC-9CF0-413E01DAA81D> 
/Users/USER/*/Opml_Converter.app/Contents/MacOS/Opml_Converter
       0x1004c6000 -        0x1004c9fff +zlib.so (0) 
<F62754E4-EBE2-3A2C-B78A-3942155A0A04> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/zlib.so
       0x1004ed000 -        0x1004effff +time.so (0) 
<3551C948-7FEC-39A0-83F2-600A47781F59> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/time.so 

       0x1004f5000 -        0x1004f8fff +_struct.so (0) 
<B09C2F51-D3FB-3BB3-A019-1319E62AE7DF> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_struct.so 

       0x102800000 -        0x10294aff7 +org.python.python (3.4.1, [c] 
2004-2014 Python Software Foundation. - 3.4.1) 
<2E8065CE-5540-3FBF-9D5F-04044DFF0731> 
/Users/USER/*/Opml_Converter.app/Contents/Frameworks/Python.framework/Versions/3.4/Python 

       0x1029cb000 -        0x1029daff7 +_ctypes.so (0) 
<0826D76F-5793-3CF7-B66F-A7A84C380B10> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_ctypes.so 

       0x104202000 -        0x104203fff +_heapq.so (0) 
<B0E9F274-E89A-313A-8E14-FF3CBB70D03F> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_heapq.so 

       0x104287000 -        0x10439cff7 +etree.so (0) 
<467DEE63-5EBF-3EE6-9383-D187ABA4C94F> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/lxml/etree.so 

       0x1044e2000 -        0x1044e2fff +_opcode.so (0) 
<B23A0D31-4902-3220-9C59-277303D59A09> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_opcode.so 

       0x1044f0000 -        0x104501ff7 +sip.so (0) 
<C173D82C-37BC-3FE6-8450-04A184D6DDB2> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/sip.so 

       0x105ac8000 -        0x105c45ff7 +QtGui.so (0) 
<CAE6F6E7-261D-3993-8917-DC850C465AC1> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtGui.so 

       0x105d43000 -        0x10617aff7 +QtGui (5.3) 
<834FC6CC-D0A2-3B2C-B2F5-13ECA920483B> 
/Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui 

       0x10624a000 -        0x106754fff +QtCore (5.3) 
<6C09A68B-0A13-3237-A5AE-585303D42DDB> 
/Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore 

       0x1067d9000 -        0x106938ff7 +QtCore.so (0) 
<6CA7DB65-5ABF-334A-9D3E-FF1893F3BE58> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtCore.so 

       0x106a19000 -        0x106ca0fff +QtWidgets.so (0) 
<84C0E80B-7542-3CCF-876E-BD56816F90B9> 
/Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtWidgets.so 

       0x106eb9000 -        0x10737fff7 +QtWidgets (5.3) 
<49CD46B1-BD99-37B0-87A6-D30C3F1BDBE2> 
/Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets 


Any hints?

 



From brendan.simon at etrix.com.au  Sun Jun  8 14:33:08 2014
From: brendan.simon at etrix.com.au (Brendan Simon (eTRIX))
Date: Sun, 08 Jun 2014 22:33:08 +1000
Subject: [Pythonmac-SIG] Code signing py2app generated apps
In-Reply-To: <mailman.26.1402221602.19141.pythonmac-sig@python.org>
References: <mailman.26.1402221602.19141.pythonmac-sig@python.org>
Message-ID: <53945804.9070706@etrix.com.au>


> On 6/7/14, 9:31 AM, Brendan Simon (eTRIX) wrote:
>> Is there anything special one needs to do to sign py2app generated
>> apps ?
>>
>> I've tried:  codesign -s <certificate-identifier> <path-to-my-app>
>>
>> but I when verifying it with "codesign -v" I get:
>>
>>      src/dist/SureAnalysis.app: Unknown format in import.
>>      In architecture: i386
>>
>> The certificate is a .p12 file that was imported with KeyChain.app to
>> the System destination keychain.
>
> This works for me:
>
> codesign --deep --signature-size 9400  -f -s "Developer ID
> Application: Kevin Walzer"  cbk/QuickWho.app
>
> I use cx_freeze in this app, not py2app, but this also worked for me
> with py2app.
>
> --Kevin

Tried the above codesign suggestion but I still get the same error =>
Unknown format in import.

The certificate issuer is: DigiCert SHA2 Assured ID Code Signing CA

The app uses python2.7 (32-bit) and wxPython 2.8.12.1 (Carbon). 
Universal bundles with i386 and ppc architectures.

I wonder if building the app to use only 64-bit and/or i386/x86_64
architectures and/or wxPython (Cocoa) would make a difference ?

Thanks for any thoughts :)
Brendan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20140608/120efbfc/attachment.html>

From chris.barker at noaa.gov  Wed Jun 11 17:58:52 2014
From: chris.barker at noaa.gov (Chris Barker)
Date: Wed, 11 Jun 2014 08:58:52 -0700
Subject: [Pythonmac-SIG] Building compatible dependencies
Message-ID: <CALGmxEKA=c_pDeCt6Yk0Tm8e7ZDvPO20RNixxD9iR61fisM2YQ@mail.gmail.com>

Hi folks,

I know it'a at least theoretically possible to build libs under 10.9 that
will work on 10.6 -- specifically compatible with the python.org python
binaries.

But I"m having trouble finding documentation of what flags you need.

MACOSX_DEPLOYMENT_TARGET=10.6

should be required -- but anything else?

personally, I've solved this by building on the oldest machine I want to
support, but that's not always possible anymore.

Anyone have an example?

-thanks,
  --Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20140611/4e4f9243/attachment.html>

From matthew.brett at gmail.com  Wed Jun 11 22:28:42 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 11 Jun 2014 21:28:42 +0100
Subject: [Pythonmac-SIG] Building compatible dependencies
In-Reply-To: <CALGmxEKA=c_pDeCt6Yk0Tm8e7ZDvPO20RNixxD9iR61fisM2YQ@mail.gmail.com>
References: <CALGmxEKA=c_pDeCt6Yk0Tm8e7ZDvPO20RNixxD9iR61fisM2YQ@mail.gmail.com>
Message-ID: <CAH6Pt5rZ0hn3BXLn-mEM+nAGyydV0gXtf6EY6T1B3+e=xNNryw@mail.gmail.com>

Hi,

On Wed, Jun 11, 2014 at 4:58 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> Hi folks,
>
> I know it'a at least theoretically possible to build libs under 10.9 that
> will work on 10.6 -- specifically compatible with the python.org python
> binaries.
>
> But I"m having trouble finding documentation of what flags you need.
>
> MACOSX_DEPLOYMENT_TARGET=10.6
>
> should be required -- but anything else?
>
> personally, I've solved this by building on the oldest machine I want to
> support, but that's not always possible anymore.

Have you run into any problems using the deployment target = 10.6?

I haven't with wheels at least - I'm building on 10.9 and testing on 10.6

Cheers,

Matthew

From nad at acm.org  Wed Jun 11 23:09:54 2014
From: nad at acm.org (Ned Deily)
Date: Wed, 11 Jun 2014 14:09:54 -0700
Subject: [Pythonmac-SIG] Building compatible dependencies
References: <CALGmxEKA=c_pDeCt6Yk0Tm8e7ZDvPO20RNixxD9iR61fisM2YQ@mail.gmail.com>
 <CAH6Pt5rZ0hn3BXLn-mEM+nAGyydV0gXtf6EY6T1B3+e=xNNryw@mail.gmail.com>
Message-ID: <nad-5A47E9.14095411062014@news.gmane.org>

In article 
<CAH6Pt5rZ0hn3BXLn-mEM+nAGyydV0gXtf6EY6T1B3+e=xNNryw at mail.gmail.com>,
> On Wed, Jun 11, 2014 at 4:58 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> > I know it'a at least theoretically possible to build libs under 10.9 that
> > will work on 10.6 -- specifically compatible with the python.org python
> > binaries.
> >
> > But I"m having trouble finding documentation of what flags you need.
> >
> > MACOSX_DEPLOYMENT_TARGET=10.6
> >
> > should be required -- but anything else?
> >
> > personally, I've solved this by building on the oldest machine I want to
> > support, but that's not always possible anymore.
> 
> Have you run into any problems using the deployment target = 10.6?
> 
> I haven't with wheels at least - I'm building on 10.9 and testing on 10.6

It all depends on what you are building.  I assume you're talking about 
non-Python packages here.  Many C modules won't be a problem but some 
will if they use OS-supplied APIs that have changed or been added 
between the deployment target version of OS X and the build systems's 
target.  If you need to support the full range of systems, your safest 
best remains to build on deployment target system.  Otherwise, until 
proven otherwise for the particular package, you should be using the SDK 
for the deployment target version and hope that the build system 
(Makefile, whatever) for the package builds correctly with an SDK.  In 
many cases it will because Apple cleverly hid much of the SDK and 
universal arch complexity under the covers in the compiler driver 
wrappers for cc/gcc/clang.  Basically when you use an SDK, the Apple 
compiler driver automatically prepends the SDK path to all "system" 
files, those beginning with /System/Library, /Library, and /usr, so that 
they are picked up from the SDK directory rather than from the running 
system.   But, if the package's build process does something clever, 
like making its own decisions about where to look for libs or include 
files that does not take the SDK path into account, you can end up with 
subtle errors, where the package build is basing decisions on the build 
system's installed include files (i.e. the 10.9 version) whereas the 
compiler is actually building with the SDK version (i.e. 10.6) of the 
file.  (Builds of Python itself have run into this problem in the past.)

If you want to fully support universal architectures (Intel-32 and 
Intel-64 for the python.org 64-bit/32-bit installers), you also need to 
build universal libraries.  Adding -arch i386 and -arch x86_64 will 
usually work but not always (OpenSSL is an example of one where it 
doesn't).  If the package build makes arch dependent decisions at 
configure time (or the equivalent) or arch-dependent values are in 
generated include files or something similar, the safest approach is to 
build each arch separately and then use lipo to combine the separate 
archs into universal file(s) to be installed.  Fortunately, most popular 
libs either now natively support universal builds or someone has figured 
out how to do it.  The build recipes in MacPorts or homebrew can be of 
help here.

On the most recent versions of OS X, particularly on 10.9, there is 
better support from the command line tools for building with SDKs by 
setting the SDKROOT and DEVELOPER_DIR environment variables.  See the 
man page for xcrun (man 1 xcrun) for more details.

Also, note that when building C extension modules via Distutils in 
current Pythons from python.org, the SDK used to build Python is looked 
for in its original path (for example, /Developer/SDKs/MacOSX10.6.sdk) 
and, if not found there, the ext module build proceeds without an SDK, 
using the headers and libs of the installed command line tools.  Most of 
the time that is fine if you are building something to be used solely on 
the build system's OS level and probably for later systems.

-- 
 Ned Deily,
 nad at acm.org


From karstenwo at googlemail.com  Fri Jun 13 21:45:41 2014
From: karstenwo at googlemail.com (Karsten Wolf)
Date: Fri, 13 Jun 2014 21:45:41 +0200
Subject: [Pythonmac-SIG] py2app & pillow
Message-ID: <4C5CE95D-8943-4438-8428-1DC8043D2F13@googlemail.com>

Hi,

in an py2app app I replaced the thumbnail mechanism from sips (via os.system) to Pillow. The resulting app size went from 11MB to 50 MB for the inclusion of the complete TCL/TK stuff.

Is there an easy way to reduce that?

Both, Python 2.7.6 and Pillow are compiled for intel 32bit on OSX10.6


-karsten