From ronaldoussoren at mac.com Tue Dec 6 11:59:48 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 06 Dec 2016 17:59:48 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released Message-ID: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> Hi, I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: class MyObject (NSObject): def amethod(self, a, b): pass This would work in previous versions, but no longer works because the method name suggests that this is a method without arguments (the translation to an Objective-C selector contains no colons). The workaround for this is easy enough: use the decorator ?objc.python_method? on methods that won?t be called from Objective-C. This change was necessary to make it possible to use generic decorators on selectors. Ronald From ronaldoussoren at mac.com Tue Dec 6 13:36:06 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 06 Dec 2016 19:36:06 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> Message-ID: > On 6 Dec 2016, at 19:19, Glyph Lefkowitz wrote: > > >> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren wrote: >> >> Hi, >> >> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. > > ??? > >> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >> >> class MyObject (NSObject): >> def amethod(self, a, b): pass > > Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? > > Is there any chance that now this release is done, wheel builds might be on the horizon? :) Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) Ronald From ronaldoussoren at mac.com Tue Dec 6 15:17:10 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 06 Dec 2016 21:17:10 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> Message-ID: <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> > On 6 Dec 2016, at 20:30, Glyph Lefkowitz wrote: > > >> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren wrote: >> >> >>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz wrote: >>> >>> >>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren wrote: >>>> >>>> Hi, >>>> >>>> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. >>> >>> ??? >>> >>>> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >>>> >>>> class MyObject (NSObject): >>>> def amethod(self, a, b): pass >>> >>> Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). >> >> It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? >> >>> >>> Is there any chance that now this release is done, wheel builds might be on the horizon? :) >> >> Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) > > If manual source releasing is `python setup.py sdist && twine upload dist/*`, then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine upload dist/*`. It doesn't seem like that should be a crushing maintenance burden :-). > > Although perhaps there's something I'm missing? The subtleties of binary compatibility often escape me. That?s about it, although I don?t use twine (see >). I?m slightly worried about binary compatibility and want to have some way to do smoke tests of the generated wheels on various platforms. In theory binary compatibility shouldn?t be a problem, I used to do builds on newer OSX releases when the system where the application was running but that was a couple of releases ago (both of PyObjC and OSX). Binary compatibility is likely a larger problem for CPython itself, due to configure picking up some definitions that aren?t available on older OSX releases (IIRC functions like openat(2) are new in 10.10, that causes problems with CPython 3.5 that uses there functions when avaiable. Nothing too hard, but also not something I have a real need for at the moment (and adding weak-linking code-paths could result in patches that won?t be accepted?). BTW. The reason I?m avoiding this work is more that I?d like to be able to kick of a script that runs a long time and reports on test results on a number of OSX and Python versions, instead of me doing that work. I think I have a plan to get there, and that should make it fairly trivial to generate wheels (and sdists) as a side effect of the test run. Anyways, there may be a 3.2.1 release by the end of the week, I just noticed that building PyObjC on 10.12 doesn?t work when using python 2.7, I apparently only tested python 2.7 on older OSX releases :-( Ronald > > -glyph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Tue Dec 6 15:55:57 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 06 Dec 2016 21:55:57 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2 released In-Reply-To: <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com> Message-ID: <76A9B612-A93E-4A17-830D-4BA34867A4B9@mac.com> > On 6 Dec 2016, at 21:43, Glyph Lefkowitz wrote: > > >> Anyways, there may be a 3.2.1 release by the end of the week, I just noticed that building PyObjC on 10.12 doesn?t work when using python 2.7, I apparently only tested python 2.7 on older OSX releases :-( > > Thanks for saving me some time - I was just about to test that configuration :). It works fine on 10.11, which is what this machine is running! What version of Xcode do you use? And do you use a framework build of Python? The issue I saw earlier should be present on 10.11 as well when using Xcode 8.1 (which includes the 10.12 SDK) Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Wed Dec 7 03:21:38 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 07 Dec 2016 09:21:38 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com>

Message-ID: <4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> > On 7 Dec 2016, at 00:28, Glyph Lefkowitz wrote: > > Was this intentionally off-list? (Feel free to forward my reply back to the list if not). It wasn?t and I?ll continue the conversation on-list. > >> On Dec 6, 2016, at 2:31 PM, Ronald Oussoren > wrote: >> >>> >>> On 6 Dec 2016, at 21:43, Glyph Lefkowitz > wrote: >>> >>>> >>>> On Dec 6, 2016, at 12:17 PM, Ronald Oussoren > wrote: >>>> >>>>> >>>>> On 6 Dec 2016, at 20:30, Glyph Lefkowitz > wrote: >>>>> >>>>> >>>>>> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren > wrote: >>>>>> >>>>>> >>>>>>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz > wrote: >>>>>>> >>>>>>> >>>>>>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>>> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >>>>>>>> >>>>>>>> class MyObject (NSObject): >>>>>>>> def amethod(self, a, b): pass >>>>>>> >>>>>>> Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). >>>>>> >>>>>> It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? >>>>>> >>>>>>> >>>>>>> Is there any chance that now this release is done, wheel builds might be on the horizon? :) >>>>>> >>>>>> Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) >>>>> >>>>> If manual source releasing is `python setup.py sdist && twine upload dist/*`, then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine upload dist/*`. It doesn't seem like that should be a crushing maintenance burden :-). >>>>> >>>>> Although perhaps there's something I'm missing? The subtleties of binary compatibility often escape me. >>>> >>>> That?s about it, although I don?t use twine (see >). I?m slightly worried >>>> about binary compatibility and want to have some way to do smoke tests of the generated wheels on various platforms. >>> >>> Twine is strongly recommended by the packaging community these days. Mostly the security problems with `setup.py upload` have been fixed, but there's no easy way to check, especially on the command line, so it remains somewhat risky to use, especially in a scripted context. >>> >>> That said, the process is mostly the same; just stick `bdist_wheel` in on that command line somewhere before `upload` and you're good to go. >> >> Building wheels isn?t as bad as I thought, turns out I can build wheels for all subprojects of PyObjC on 10.12 with a small tweak of the setup.py file, even for the subprojects that won?t work on 10.12 (luckily none of those contain C extensions). > > Excellent! > >> I now have a script that builds and collects sdists as well as wheels for Python 2.7, 3.4, 3.5 and 3.6. There now definitely will be a 3.2.1 release later this week, even if it only contains wheels (and possibly the 2.7 issue I ran into). I?ll probably only provide wheels for the 32/64-bit Intel installer on python.org (which is the default these days), possibly with some fine-tuning of the platform tag in the wheel name to support Homebrew as well (which AFAIK installs a 64-bit Python). > > Oh, is the system python not 64-bit? sys.maxint suggests that it is? The system python is both 32-bit and 64-bit, depending on how you start it: ronald at Menegroth[0]$ file /usr/bin/python /usr/bin/python: Mach-O universal binary with 2 architectures: [i386: Mach-O executable i386] [x86_64: Mach-O 64-bit executable x86_64] /usr/bin/python (for architecture i386): Mach-O executable i386 /usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64 IIRC you have to use some special command-line option to specify the architecture to use with the system python, with python.org binaries you can use ?arch -i386 python? to select the 32-bit binary. There are two installers on python.org : one supports i386 and x86_64 on OSX 10.6 or later, the other supports i386 and ppc on OSX 10.5 (and possibly 10.4 as well). The latter is no longer relevant. Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that?s something users won?t see anyway. If that doesn?t work out I?ll install homebrew on my build machine and have the build script generate wheels for that as well. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Wed Dec 7 03:23:54 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 07 Dec 2016 09:23:54 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2 released puObjC In-Reply-To: References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com> <76A9B612-A93E-4A17-830D-4BA34867A4B9@mac.com> Message-ID: <4B189FF3-4845-4C87-B34C-E77ECC599917@mac.com> > On 7 Dec 2016, at 01:49, Christopher Barker wrote: > > I haven't been involved for a while, but this gitHub org: > > https://github.com/MacPython > > Is doing a lot of wheel building, and I think they are using CIs to build and test. > > Maybe they could add pyObjC > > Or you could see what they have set up. They appear to use travis to build, with some script to sanitise binary dependencies (that is, copy non-system shared libraries into the wheel). Might be interesting to look into for PyObjC as well, but for now manual building will do. Ronald > > -CHB > > > > On Tue, Dec 6, 2016 at 12:56 PM Ronald Oussoren > wrote: >> On 6 Dec 2016, at 21:43, Glyph Lefkowitz > wrote: > >> >> >>> Anyways, there may be a 3.2.1 release by the end of the week, I just noticed that building PyObjC on 10.12 doesn?t work when using python 2.7, I apparently only tested python 2.7 on older OSX releases :-( >> > >> Thanks for saving me some time - I was just about to test that configuration :). It works fine on 10.11, which is what this machine is running! > > What version of Xcode do you use? And do you use a framework build of Python? The issue I saw earlier should be present on 10.11 as well when using Xcode 8.1 (which includes the 10.12 SDK) > > Ronald > > _______________________________________________ > > 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: From ronaldoussoren at mac.com Thu Dec 8 06:37:09 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 08 Dec 2016 12:37:09 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <35B84BA1-81A3-45B3-8E1E-FC0223B2F6CD@twistedmatrix.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com>

<4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> <35B84BA1-81A3-45B3-8E1E-FC0223B2F6CD@twistedmatrix.com> Message-ID: <4BE6A3FA-F519-4B91-803F-74FD3F7CE852@mac.com> > On 8 Dec 2016, at 00:40, Glyph Lefkowitz wrote: >> >> >> Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that?s something users won?t see anyway. If that doesn?t work out I?ll install homebrew on my build machine and have the build script generate wheels for that as well. > > You shouldn't need to do this; and in fact you shouldn't do it :). If you tweak the platform tag, you'll break Pip's ability to discover the wheel as valid-to-install for the current platform. Platform tags are a descriptive mechanism for Python, Pip, and Setuptools, not a point for user extensibility. I know how platform tags work, I?ve read the relevant PEPs when the were proposed. The ?tweak? I wanted to use is documented as ?Compressed Tag Sets? in PEP 425, and is how the python version is added to the wheel filename for wheels supporting both python2 and python3, as in: pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl This should work in the platform tag as well, and is already used by wheels for matplotlib (see https://pypi.python.org/pypi/matplotlib ). > > > There are a lot of fiddly nuances here, but basically, "intel" is the architecture for "fat binary, intel", and "x86_64" is the architecture for "64-bit". (I have no idea what the story is on 10.5 and previous but IMHO you can skip bothering to build wheels for them for now). If you want to build release wheels, just build "intel" (fat binary) and any Python will be happy with them. I wrote the distutils code that sets the platform to a sane value for fat binaries on OSX ;-). > > Regardless of what architecture you run it under - and I did test this before sending this message :) - system python will produce _intel wheels; Homebrew produces _x86-64 wheels. Cracking one open, this is what both 32- and 64-bit system python built: > > $ file CoreFoundation/_CoreFoundation.so > CoreFoundation/_CoreFoundation.so: Mach-O universal binary with 2 architectures: [i386: Mach-O bundle i386] [x86_64: Mach-O 64-bit bundle x86_64] > CoreFoundation/_CoreFoundation.so (for architecture i386): Mach-O bundle i386 > CoreFoundation/_CoreFoundation.so (for architecture x86_64): Mach-O 64-bit bundle x86_64 > > and this is what Homebrew built: > > $ file CoreFoundation/_CoreFoundation.so > CoreFoundation/_CoreFoundation.so: Mach-O 64-bit bundle x86_64 > > Homebrew could happily 'pip install *.whl' in the directory of _intel wheels built by system Python, and I imported the module and made a couple of objc method calls, which worked fine, just to make double extra sure my understanding is correct. That?s cool, this means pip did implement the logic that?s needed to understand that ?intel? is an acceptable architecture when looking for a wheel for an ?x86_64? build of CPython. > > This is probably worth reading, as it explains the above in a lot more detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels . But the lede is: just use the default behavior of a fat binary Python, it will do the right thing :). Looking at that page the relevant logic was added in pip 6, that?s old enough to not worry about using a compressed tag set for the platform. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Fri Dec 9 04:44:25 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 09 Dec 2016 10:44:25 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <73B25FA3-1401-4560-AF51-CB282852481A@twistedmatrix.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com>

<4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> <35B84BA1-81A3-45B3-8E1E-FC0223B2F6CD@twistedmatrix.com> <4BE6A3FA-F519-4B91-803F-74FD3F7CE852@mac.com> <73B25FA3-1401-4560-AF51-CB282852481A@twistedmatrix.com> Message-ID: > On 8 Dec 2016, at 23:55, Glyph Lefkowitz wrote: > >> >> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren > wrote: >> >> >>> On 8 Dec 2016, at 00:40, Glyph Lefkowitz > wrote: >>>> >>>> >>>> Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that?s something users won?t see anyway. If that doesn?t work out I?ll install homebrew on my build machine and have the build script generate wheels for that as well. >>> >>> You shouldn't need to do this; and in fact you shouldn't do it :). If you tweak the platform tag, you'll break Pip's ability to discover the wheel as valid-to-install for the current platform. Platform tags are a descriptive mechanism for Python, Pip, and Setuptools, not a point for user extensibility. >> >> I know how platform tags work, I?ve read the relevant PEPs when the were proposed. The ?tweak? I wanted to use is documented as ?Compressed Tag Sets? in PEP 425, and is how the python version is added to the wheel filename for wheels supporting both python2 and python3, as in: >> >> pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl >> >> This should work in the platform tag as well, and is already used by wheels for matplotlib (see https://pypi.python.org/pypi/matplotlib ). > > Aah, I was reading you backwards. I thought you were saying something about inventing a platform tag for Homebrew (since they don't have one of their own; they build specifically to be compatible with system python). This makes sense. That explains the confusion. > >>> There are a lot of fiddly nuances here, but basically, "intel" is the architecture for "fat binary, intel", and "x86_64" is the architecture for "64-bit". (I have no idea what the story is on 10.5 and previous but IMHO you can skip bothering to build wheels for them for now). If you want to build release wheels, just build "intel" (fat binary) and any Python will be happy with them. >> >> I wrote the distutils code that sets the platform to a sane value for fat binaries on OSX ;-). > > Heh. I think we both know a little too much about this for our own good :-). > >> That?s cool, this means pip did implement the logic that?s needed to understand that ?intel? is an acceptable architecture when looking for a wheel for an ?x86_64? build of CPython. > > I believe it understands the tags pretty thoroughly; I haven't tested, but I believe it also knows that an x86_64 wheel won't cut it on an 'intel' python because it might blow up later. > >>> >>> This is probably worth reading, as it explains the above in a lot more detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels . But the lede is: just use the default behavior of a fat binary Python, it will do the right thing :). >> >> Looking at that page the relevant logic was added in pip 6, that?s old enough to not worry about using a compressed tag set for the platform. > > Cool. I'm really looking forward to never building pyobjc again :-). :-) I?ve written some scripts to help me with doing the release, by scaling back the scope these scripts got a lot simpler and more importantly actually got written. Annoyingly the testsuite runner found some issues that I had missed before because I don?t regularly all python versions and architectures. The new test runner should make it a lot easier to do comprehensive testing, a test run will still take a lot of time but I won?t have to be present for that. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon Dec 12 04:25:25 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 12 Dec 2016 10:25:25 +0100 Subject: [Pythonmac-SIG] PyObjC 3.2.1 released Message-ID: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> Hi, I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. I?ve tested the wheels on OSX 10.12 with the Python.org ?intel? installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.h.jaffe at gmail.com Mon Dec 12 15:06:41 2016 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Mon, 12 Dec 2016 20:06:41 +0000 Subject: [Pythonmac-SIG] PyObjC 3.2.1 released In-Reply-To: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> References: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> Message-ID: <1e0b3fe9-94f7-9f97-f32b-e62bae887030@gmail.com> Hi Ronald, On 12/12/2016 09:25, Ronald Oussoren wrote: > Hi, > > I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small > issues in PyObjC 3.2, but the primary new feature is that there are now > wheels on PyPI. > > I?ve tested the wheels on OSX 10.12 with the Python.org > ?intel? installers (the default download option for > the OSX installers) and Homebrew. The wheels should also work fine with > older OSX releases. > Thanks. I'll also note that when used with `pip2 install --upgrade --ignore-installed` this solves the problem discussed a few weeks ago regarding clashes with the Apple-installed version on Framework (python.org) builds of Python. (Previously, `--ignore-installed` failed for some of the packages.) Yours, Andrew > Ronald > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/xeonphi > > > > _______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > From ronaldoussoren at mac.com Tue Dec 13 03:49:09 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 13 Dec 2016 09:49:09 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2.1 released In-Reply-To: References: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> Message-ID: > On 13 Dec 2016, at 04:02, Glyph Lefkowitz wrote: > > >> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren > wrote: >> >> Hi, >> >> I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. >> >> I?ve tested the wheels on OSX 10.12 with the Python.org ?intel? installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. > > Thank you *so* much, Ronald :D. I installed pyobjc onto my laptop just now and didn't even have to go get an icepack out of the freezer first :-). In under ten seconds, no less, for both python 3.5 and python 2.7. A glorious day, to be sure. Great to hear that. > > One minor note - I do notice that the 'pyobjc' package itself has no wheel, even though all its dependents do. Any chance you could upload 2.7/3.5 wheels for that as well? It would just complete the set :-). That is intentional. The setup.py for the package pyobjc calculates the ?install_requires? list at runtime to ensure it will only install framework wrappers for frameworks that are actually present. It might be possible to use conditional dependencies for that (see [1]), but I haven?t checked yet if those compare version numbers as structured data or strings. PEP 426 seems to indicate they are just strings, and that would be less useful. I guess a wheel for the ?pyobjc? package could just depend on all framework wrappers, that would install some code that isn?t relevant for the current machine but wouldn?t result in install failures (which could happen when installing all framework wrappers from source). Ronald [1]: http://wheel.readthedocs.io/en/latest/#defining-conditional-dependencies > > Thanks again; this is fabulous, > > -glyph > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Pyobjc-dev mailing list > Pyobjc-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Tue Dec 6 13:19:51 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 6 Dec 2016 10:19:51 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> Message-ID: <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> > On Dec 6, 2016, at 8:59 AM, Ronald Oussoren wrote: > > Hi, > > I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. ??? > There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: > > class MyObject (NSObject): > def amethod(self, a, b): pass Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). Is there any chance that now this release is done, wheel builds might be on the horizon? :) -glyph From glyph at twistedmatrix.com Tue Dec 6 14:30:01 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 6 Dec 2016 11:30:01 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> Message-ID: <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> > On Dec 6, 2016, at 10:36 AM, Ronald Oussoren wrote: > > >> On 6 Dec 2016, at 19:19, Glyph Lefkowitz wrote: >> >> >>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren wrote: >>> >>> Hi, >>> >>> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. >> >> ??? >> >>> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >>> >>> class MyObject (NSObject): >>> def amethod(self, a, b): pass >> >> Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). > > It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? > >> >> Is there any chance that now this release is done, wheel builds might be on the horizon? :) > > Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) If manual source releasing is `python setup.py sdist && twine upload dist/*`, then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine upload dist/*`. It doesn't seem like that should be a crushing maintenance burden :-). Although perhaps there's something I'm missing? The subtleties of binary compatibility often escape me. -glyph From glyph at twistedmatrix.com Tue Dec 6 15:43:29 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 6 Dec 2016 12:43:29 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> Message-ID: <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com> > On Dec 6, 2016, at 12:17 PM, Ronald Oussoren wrote: > >> >> On 6 Dec 2016, at 20:30, Glyph Lefkowitz > wrote: >> >> >>> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren > wrote: >>> >>> >>>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz > wrote: >>>> >>>> >>>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren > wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. >>>> >>>> ??? >>>> >>>>> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >>>>> >>>>> class MyObject (NSObject): >>>>> def amethod(self, a, b): pass >>>> >>>> Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). >>> >>> It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? >>> >>>> >>>> Is there any chance that now this release is done, wheel builds might be on the horizon? :) >>> >>> Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) >> >> If manual source releasing is `python setup.py sdist && twine upload dist/*`, then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine upload dist/*`. It doesn't seem like that should be a crushing maintenance burden :-). >> >> Although perhaps there's something I'm missing? The subtleties of binary compatibility often escape me. > > That?s about it, although I don?t use twine (see >). I?m slightly worried > about binary compatibility and want to have some way to do smoke tests of the generated wheels on various platforms. Twine is strongly recommended by the packaging community these days. Mostly the security problems with `setup.py upload` have been fixed, but there's no easy way to check, especially on the command line, so it remains somewhat risky to use, especially in a scripted context. That said, the process is mostly the same; just stick `bdist_wheel` in on that command line somewhere before `upload` and you're good to go. > In theory binary compatibility shouldn?t be a problem, I used to do builds on newer OSX releases when the system where the application was running but that was a couple of releases ago (both of PyObjC and OSX). > > Binary compatibility is likely a larger problem for CPython itself, due to configure picking up some definitions that aren?t available on older OSX releases (IIRC functions like openat(2) are new in 10.10, that causes problems with CPython 3.5 that uses there functions when avaiable. Nothing too hard, but also not something I have a real need for at the moment (and adding weak-linking code-paths could result in patches that won?t be accepted?). > > BTW. The reason I?m avoiding this work is more that I?d like to be able to kick of a script that runs a long time and reports on test results on a number of OSX and Python versions, instead of me doing that work. I think I have a plan to get there, and that should make it fairly trivial to generate wheels (and sdists) as a side effect of the test run. IMHO the pareto principle applies here. Even with potentially "bad" (untested) wheels, for most people, using recent OS X, `pip instal pyobjc` will go a zillion times faster (which is useful even for expert developers), and will work even on computers without a compiler installed. This is especially useful for e.g. kids trying out programming for the first time on their Mac and trying to run some project from PyPI; it can make the difference between "works perfectly" and "totally inscrutable failure". For a lot of projects you can just say "oh, just run xcode-select --install", but for pyobjc you actually need all the SDK headers, so you need an apple ID and at that point we've already lost the game for such casual users. (To be clear, this is not a hypothetical concern; I have had several potentially interested students give up on Python and instead learn AppleScript due to this problem.) For those on very old OSes (10.9 is not supported by Apple any more, is it?) pip install --no-binary :all: will helpfully use sdists from PyPI and do local builds as before; and given the distribution landscape, those users probably have to do that anyway. So I think doing the dumb, untested wheel release will still be a huge benefit overall, and does not break things irreparably even if it works very poorly. In the absolute nightmare worst-case scenario where the uploaded wheels just cause impossible to diagnose segfaults for some users, a +.1 release bump with only sdists will restore things back to normal. (But if this were the case, it would not be possible to build apps that users could run with pyobjc, and... that seems to work fine :) so it seems likely to work.) Basically, wheels will definitely make the situation a lot better for a really big audience, while possibly making it a little worse for a very small audience. I will happily volunteer to do wheel uploads myself if you would add me to the project on PyPI. I'd rather do the builds straight from the same environment doing the testing and sdist (i.e. yours) but I am fairly confident that I can build working pyobjc wheels since I do it every couple of days for my own use :). > Anyways, there may be a 3.2.1 release by the end of the week, I just noticed that building PyObjC on 10.12 doesn?t work when using python 2.7, I apparently only tested python 2.7 on older OSX releases :-( Thanks for saving me some time - I was just about to test that configuration :). It works fine on 10.11, which is what this machine is running! -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Tue Dec 6 16:15:34 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 6 Dec 2016 13:15:34 -0800 Subject: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2 released In-Reply-To: <76A9B612-A93E-4A17-830D-4BA34867A4B9@mac.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com> <76A9B612-A93E-4A17-830D-4BA34867A4B9@mac.com> Message-ID: > On Dec 6, 2016, at 12:55 PM, Ronald Oussoren wrote: > > >> On 6 Dec 2016, at 21:43, Glyph Lefkowitz > wrote: >> >> >>> Anyways, there may be a 3.2.1 release by the end of the week, I just noticed that building PyObjC on 10.12 doesn?t work when using python 2.7, I apparently only tested python 2.7 on older OSX releases :-( >> >> Thanks for saving me some time - I was just about to test that configuration :). It works fine on 10.11, which is what this machine is running! > > What version of Xcode do you use? And do you use a framework build of Python? The issue I saw earlier should be present on 10.11 as well when using Xcode 8.1 (which includes the 10.12 SDK) So... technically the answer for Xcode is "8.1" but when I launched it to find out it asked me to "install required components"... but even after installing them it builds fine (with pip --no-use-wheel to avoid using my previously-cached wheels from the earlier attempt). I also tried pip wheel --no-cache-dir just in case; it works that way as well. I use a framework build of 2.7, from Homebrew. Given the confusion you've expressed, I went ahead and tried to build this for my Sierra machine as well, and it worked there too. So as far as I can tell there is no bug, but I haven't tried with the system-provided Python. Happy to report any other salient details though; let me know. -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz at learning-python.com Tue Dec 6 21:43:42 2016 From: lutz at learning-python.com (Mark Lutz) Date: Wed, 07 Dec 2016 02:43:42 -0000 Subject: [Pythonmac-SIG] Phantom Dock menu entries for tkinter dialogs on Mac Message-ID: <3tYNBK16wFzFqdn@mail.python.org> When using Tk on a Mac (Python 3.5, ActiveState Tk 8.5, Mac 10.11), why does the Python launcher retain Dock right-click menu entries for every Toplevel window that has been closed? This doesn't happen for common dialogs, but does for every custom dialog the closes with a widget.destroy(). It also happens for IDLE dialogs that are not withdrawn/redrawn, so it seems fairly pervasive. A simple demo of the problem is attached below: every "destroy" popup lingers on in the launcher's Dock menu after it's closed (whether by the red "X" or the widget.destroy() callback), and remains in the Dock menu until the main window is closed (by widget.quit() or otherwise). This happens whether the script is run by click or command line. Any ideas? The phantom Dock menu entries are useless (and even buggy) for modal dialogs that have been dismissed. Thanks, --Mark Lutz, http://learning-python.com -------- from tkinter import * def destroyer(): popup = Toplevel() popup.title('destroyer') Button(popup, text='Destroy', command=popup.destroy, width=40).pack() def quitter(): popup = Toplevel() popup.title('quitter') Button(popup, text='Quit', command=popup.quit, width=40).pack() root = Tk() root.title('root') Button(root, text='destroyer', command=destroyer, width=40).pack() Button(root, text='quitter', command=quitter, width=40).pack() root.mainloop() -------- From glyph at twistedmatrix.com Wed Dec 7 18:40:23 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 7 Dec 2016 15:40:23 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com>

<4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> Message-ID: <35B84BA1-81A3-45B3-8E1E-FC0223B2F6CD@twistedmatrix.com> > On Dec 7, 2016, at 12:21 AM, Ronald Oussoren wrote: > > >> On 7 Dec 2016, at 00:28, Glyph Lefkowitz > wrote: >> >> Was this intentionally off-list? (Feel free to forward my reply back to the list if not). > > It wasn?t and I?ll continue the conversation on-list. > >> >>> On Dec 6, 2016, at 2:31 PM, Ronald Oussoren > wrote: >>> >>>> >>>> On 6 Dec 2016, at 21:43, Glyph Lefkowitz > wrote: >>>> >>>>> >>>>> On Dec 6, 2016, at 12:17 PM, Ronald Oussoren > wrote: >>>>> >>>>>> >>>>>> On 6 Dec 2016, at 20:30, Glyph Lefkowitz > wrote: >>>>>> >>>>>> >>>>>>> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren > wrote: >>>>>>> >>>>>>> >>>>>>>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz > wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren > wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I?ve pushed PyObjC 3.2 to PyPI (finally?). The major new feature in this version is support for OSX 10.12 (Sierra) and the new APIs introduced in this version of OSX. >>>>>>>> >>>>>>>> ??? >>>>>>>> >>>>>>>>> There is also a backward incompatible change: the default method signature is calculated differently than before. This will primarily affect code that adds python-only method to a class, like so: >>>>>>>>> >>>>>>>>> class MyObject (NSObject): >>>>>>>>> def amethod(self, a, b): pass >>>>>>>> >>>>>>>> Huh, I didn't even realize that was possible before. Hopefully none of my code will be affected as a result :-). >>>>>>> >>>>>>> It wasn?t really documented, but I wouldn?t be surprised if someone relies on the previous behavior? >>>>>>> >>>>>>>> >>>>>>>> Is there any chance that now this release is done, wheel builds might be on the horizon? :) >>>>>>> >>>>>>> Maybe. The important bit w.r.t. wheel builds is that they must be automated, otherwise releases take too much time and I end up not doing releases at all. That said, automating this shouldn?t be too hard and should be able to save me some time in the end (I currently also test manually?) >>>>>> >>>>>> If manual source releasing is `python setup.py sdist && twine upload dist/*`, then "manual" wheel releasing is `python setup.py sdist bdist_wheel && twine upload dist/*`. It doesn't seem like that should be a crushing maintenance burden :-). >>>>>> >>>>>> Although perhaps there's something I'm missing? The subtleties of binary compatibility often escape me. >>>>> >>>>> That?s about it, although I don?t use twine (see >). I?m slightly worried >>>>> about binary compatibility and want to have some way to do smoke tests of the generated wheels on various platforms. >>>> >>>> Twine is strongly recommended by the packaging community these days. Mostly the security problems with `setup.py upload` have been fixed, but there's no easy way to check, especially on the command line, so it remains somewhat risky to use, especially in a scripted context. >>>> >>>> That said, the process is mostly the same; just stick `bdist_wheel` in on that command line somewhere before `upload` and you're good to go. >>> >>> Building wheels isn?t as bad as I thought, turns out I can build wheels for all subprojects of PyObjC on 10.12 with a small tweak of the setup.py file, even for the subprojects that won?t work on 10.12 (luckily none of those contain C extensions). >> >> Excellent! >> >>> I now have a script that builds and collects sdists as well as wheels for Python 2.7, 3.4, 3.5 and 3.6. There now definitely will be a 3.2.1 release later this week, even if it only contains wheels (and possibly the 2.7 issue I ran into). I?ll probably only provide wheels for the 32/64-bit Intel installer on python.org (which is the default these days), possibly with some fine-tuning of the platform tag in the wheel name to support Homebrew as well (which AFAIK installs a 64-bit Python). >> >> Oh, is the system python not 64-bit? sys.maxint suggests that it is? > > The system python is both 32-bit and 64-bit, depending on how you start it: > > ronald at Menegroth[0]$ file /usr/bin/python > /usr/bin/python: Mach-O universal binary with 2 architectures: [i386: Mach-O executable i386] [x86_64: Mach-O 64-bit executable x86_64] > /usr/bin/python (for architecture i386): Mach-O executable i386 > /usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64 > > IIRC you have to use some special command-line option to specify the architecture to use with the system python, with python.org binaries you can use ?arch -i386 python? to select the 32-bit binary. > > There are two installers on python.org : one supports i386 and x86_64 on OSX 10.6 or later, the other supports i386 and ppc on OSX 10.5 (and possibly 10.4 as well). The latter is no longer relevant. > > Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that?s something users won?t see anyway. If that doesn?t work out I?ll install homebrew on my build machine and have the build script generate wheels for that as well. You shouldn't need to do this; and in fact you shouldn't do it :). If you tweak the platform tag, you'll break Pip's ability to discover the wheel as valid-to-install for the current platform. Platform tags are a descriptive mechanism for Python, Pip, and Setuptools, not a point for user extensibility. There are a lot of fiddly nuances here, but basically, "intel" is the architecture for "fat binary, intel", and "x86_64" is the architecture for "64-bit". (I have no idea what the story is on 10.5 and previous but IMHO you can skip bothering to build wheels for them for now). If you want to build release wheels, just build "intel" (fat binary) and any Python will be happy with them. Regardless of what architecture you run it under - and I did test this before sending this message :) - system python will produce _intel wheels; Homebrew produces _x86-64 wheels. Cracking one open, this is what both 32- and 64-bit system python built: $ file CoreFoundation/_CoreFoundation.so CoreFoundation/_CoreFoundation.so: Mach-O universal binary with 2 architectures: [i386: Mach-O bundle i386] [x86_64: Mach-O 64-bit bundle x86_64] CoreFoundation/_CoreFoundation.so (for architecture i386): Mach-O bundle i386 CoreFoundation/_CoreFoundation.so (for architecture x86_64): Mach-O 64-bit bundle x86_64 and this is what Homebrew built: $ file CoreFoundation/_CoreFoundation.so CoreFoundation/_CoreFoundation.so: Mach-O 64-bit bundle x86_64 Homebrew could happily 'pip install *.whl' in the directory of _intel wheels built by system Python, and I imported the module and made a couple of objc method calls, which worked fine, just to make double extra sure my understanding is correct. This is probably worth reading, as it explains the above in a lot more detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels . But the lede is: just use the default behavior of a fat binary Python, it will do the right thing :). -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Thu Dec 8 17:55:20 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Thu, 8 Dec 2016 14:55:20 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2 released In-Reply-To: <4BE6A3FA-F519-4B91-803F-74FD3F7CE852@mac.com> References: <5543A5E2-EA74-4075-87AB-7C2A8DCC4AAA@mac.com> <447337E1-D79E-4018-8CDE-20A014ECA105@twistedmatrix.com> <908AD92A-4922-4CE7-A48C-57AD60FCE819@twistedmatrix.com> <3CD81D43-0186-4F51-AD3C-8885039383BC@mac.com> <5A353359-E2C0-40B9-A078-52F4F0694CF7@twistedmatrix.com>

<4A41080C-1E92-4DD8-B8E1-B34268D14C44@mac.com> <35B84BA1-81A3-45B3-8E1E-FC0223B2F6CD@twistedmatrix.com> <4BE6A3FA-F519-4B91-803F-74FD3F7CE852@mac.com> Message-ID: <73B25FA3-1401-4560-AF51-CB282852481A@twistedmatrix.com> > On Dec 8, 2016, at 3:37 AM, Ronald Oussoren wrote: > > >> On 8 Dec 2016, at 00:40, Glyph Lefkowitz > wrote: >>> >>> >>> Last time I checked systems like Homebrew only build 64-bit binaries (on anything resembling modern hardware). It should be possible to support both i386/x86_64 python.org and homebrew using the same wheel file by tweaking the platform tag. The filename of the wheels will get annoyingly long, but that?s something users won?t see anyway. If that doesn?t work out I?ll install homebrew on my build machine and have the build script generate wheels for that as well. >> >> You shouldn't need to do this; and in fact you shouldn't do it :). If you tweak the platform tag, you'll break Pip's ability to discover the wheel as valid-to-install for the current platform. Platform tags are a descriptive mechanism for Python, Pip, and Setuptools, not a point for user extensibility. > > I know how platform tags work, I?ve read the relevant PEPs when the were proposed. The ?tweak? I wanted to use is documented as ?Compressed Tag Sets? in PEP 425, and is how the python version is added to the wheel filename for wheels supporting both python2 and python3, as in: > > pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl > > This should work in the platform tag as well, and is already used by wheels for matplotlib (see https://pypi.python.org/pypi/matplotlib ). Aah, I was reading you backwards. I thought you were saying something about inventing a platform tag for Homebrew (since they don't have one of their own; they build specifically to be compatible with system python). This makes sense. >> There are a lot of fiddly nuances here, but basically, "intel" is the architecture for "fat binary, intel", and "x86_64" is the architecture for "64-bit". (I have no idea what the story is on 10.5 and previous but IMHO you can skip bothering to build wheels for them for now). If you want to build release wheels, just build "intel" (fat binary) and any Python will be happy with them. > > I wrote the distutils code that sets the platform to a sane value for fat binaries on OSX ;-). Heh. I think we both know a little too much about this for our own good :-). > That?s cool, this means pip did implement the logic that?s needed to understand that ?intel? is an acceptable architecture when looking for a wheel for an ?x86_64? build of CPython. I believe it understands the tags pretty thoroughly; I haven't tested, but I believe it also knows that an x86_64 wheel won't cut it on an 'intel' python because it might blow up later. >> >> This is probably worth reading, as it explains the above in a lot more detail: https://github.com/MacPython/wiki/wiki/Spinning-wheels . But the lede is: just use the default behavior of a fat binary Python, it will do the right thing :). > > Looking at that page the relevant logic was added in pip 6, that?s old enough to not worry about using a compressed tag set for the platform. Cool. I'm really looking forward to never building pyobjc again :-). -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosimo.lupo at daltonmaag.com Sun Dec 11 10:22:55 2016 From: cosimo.lupo at daltonmaag.com (Cosimo Lupo) Date: Sun, 11 Dec 2016 15:22:55 +0000 Subject: [Pythonmac-SIG] Examples of vendoring python 3 with py2app Message-ID: Hello list, Apologies if this is not the right place to ask about this. I would like to distribute a self-contained OSX app of an application of mine written in Python 3. I've used py2app in the past to ship apps written in Python 2.7, that linked to the system Python framework. Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my py2app-generated app. In the py2app docs I could not find information as to how to embed the python 3.5 interpreter and stdlib alongside the generated .app bundle. Could anyone point me in the right direction, and/or link to existing open source apps that do this? Thank you for your help. -- Cosimo Lupo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosimo.lupo at daltonmaag.com Mon Dec 12 06:37:34 2016 From: cosimo.lupo at daltonmaag.com (Cosimo Lupo) Date: Mon, 12 Dec 2016 11:37:34 +0000 Subject: [Pythonmac-SIG] PyObjC 3.2.1 released In-Reply-To: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> References: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> Message-ID: Hi Ronald, It's great to finally have precompiled wheels for PyObjC! Thanks so much! Cosimo -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Mon Dec 12 22:02:09 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Mon, 12 Dec 2016 19:02:09 -0800 Subject: [Pythonmac-SIG] PyObjC 3.2.1 released In-Reply-To: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> References: <8DE12125-F81A-4A29-B9B6-DAAC41136451@mac.com> Message-ID: > On Dec 12, 2016, at 1:25 AM, Ronald Oussoren wrote: > > Hi, > > I?ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. > > I?ve tested the wheels on OSX 10.12 with the Python.org ?intel? installers (the default download option for the OSX installers) and Homebrew. The wheels should also work fine with older OSX releases. Thank you *so* much, Ronald :D. I installed pyobjc onto my laptop just now and didn't even have to go get an icepack out of the freezer first :-). In under ten seconds, no less, for both python 3.5 and python 2.7. A glorious day, to be sure. One minor note - I do notice that the 'pyobjc' package itself has no wheel, even though all its dependents do. Any chance you could upload 2.7/3.5 wheels for that as well? It would just complete the set :-). Thanks again; this is fabulous, -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From kw at codebykevin.com Tue Dec 13 06:50:53 2016 From: kw at codebykevin.com (Kevin Walzer) Date: Tue, 13 Dec 2016 06:50:53 -0500 Subject: [Pythonmac-SIG] Phantom Dock menu entries for tkinter dialogs on Mac In-Reply-To: <3tYNBK16wFzFqdn@mail.python.org> References: <3tYNBK16wFzFqdn@mail.python.org> Message-ID: <40419505-2d10-e9b5-9cdb-c503f5067e39@codebykevin.com> On 12/6/16 9:43 PM, Mark Lutz wrote: > A simple demo of the problem is attached below: every "destroy" popup > lingers on in the launcher's Dock menu after it's closed (whether by > the red "X" or the widget.destroy() callback), and remains in the Dock > menu until the main window is closed (by widget.quit() or otherwise). > This happens whether the script is run by click or command line. I can't reproduce this using Tkinter built against Tk 8.6.6. There were a lot of issues with menus, the event loop, and so on that have been fixed--I don't recall seeing this exact issue but I did see similar things with "ghost windows" hanging around in a system menu after being destroyed. You may want to update your installation of Tk. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com From cosimo.lupo at daltonmaag.com Tue Dec 13 05:56:57 2016 From: cosimo.lupo at daltonmaag.com (Cosimo Lupo) Date: Tue, 13 Dec 2016 10:56:57 +0000 Subject: [Pythonmac-SIG] Examples of vendoring python 3 with py2app In-Reply-To: References:

Message-ID: Hey Andr?, Thanks for sharing this! Cosimo On 13 December 2016 at 10:48, Andr? Aulich wrote: > Hi Cosimo, > > sure, I wrote an article for you at https://moosystems.com/ > articles/14-distribute-django-app-as-native-desktop-app-01.html > > :-) > > Andr? > > On 11 Dec 2016, at 16:22, Cosimo Lupo wrote: > > Hello list, > > Apologies if this is not the right place to ask about this. > > I would like to distribute a self-contained OSX app of an application of > mine written in Python 3. I've used py2app in the past to ship apps written > in Python 2.7, that linked to the system Python framework. > Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside > my py2app-generated app. > > In the py2app docs I could not find information as to how to embed the > python 3.5 interpreter and stdlib alongside the generated .app bundle. > > Could anyone point me in the right direction, and/or link to existing open > source apps that do this? > > Thank you for your help. > > -- > Cosimo Lupo > _______________________________________________ > 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 > > > -- > Andr? Aulich moosystems > > phone: +49 (0)221 - 20 46 41 88 <+49%20221%2020464188> > mobile: +49 (0)173 - 25 17 719 <+49%20173%202517719> > > mail: andre at moosystems.com > web: https://moosystems.com > > Hanauer Weg 41 > 41564 Kaarst > Germany > > Subscribe to the moosystems newsletter at https://moosystems.com > to receive product updates and links to great > articles > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at moosystems.com Tue Dec 13 05:48:39 2016 From: andre at moosystems.com (=?utf-8?Q?Andr=C3=A9_Aulich?=) Date: Tue, 13 Dec 2016 11:48:39 +0100 Subject: [Pythonmac-SIG] Examples of vendoring python 3 with py2app In-Reply-To: References: Message-ID: Hi Cosimo, sure, I wrote an article for you at https://moosystems.com/articles/14-distribute-django-app-as-native-desktop-app-01.html :-) Andr? > On 11 Dec 2016, at 16:22, Cosimo Lupo wrote: > > Hello list, > > Apologies if this is not the right place to ask about this. > > I would like to distribute a self-contained OSX app of an application of mine written in Python 3. I've used py2app in the past to ship apps written in Python 2.7, that linked to the system Python framework. > Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my py2app-generated app. > > In the py2app docs I could not find information as to how to embed the python 3.5 interpreter and stdlib alongside the generated .app bundle. > > Could anyone point me in the right direction, and/or link to existing open source apps that do this? > > Thank you for your help. > > -- > Cosimo Lupo > _______________________________________________ > 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 -- Andr? Aulich moosystems phone: +49 (0)221 - 20 46 41 88 mobile: +49 (0)173 - 25 17 719 mail: andre at moosystems.com web: https://moosystems.com Hanauer Weg 41 41564 Kaarst Germany Subscribe to the moosystems newsletter at https://moosystems.com to receive product updates and links to great articles -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at me.com Tue Dec 13 06:20:09 2016 From: ronaldoussoren at me.com (Ronald Oussoren) Date: Tue, 13 Dec 2016 12:20:09 +0100 Subject: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra) In-Reply-To: <9B083D20-E19E-486F-A6E8-AD1167CF8E4B@twistedmatrix.com> References:

<06E9F64E-FBA4-4909-B1F0-EC58A4A73E7A@twistedmatrix.com> <74585C70-1FC2-4B9C-8A50-DFD12D4275F0@cwi.nl> <3C7A8CDB-388E-4938-A0A6-A6B8BAB6C4AF@gmail.com>

<9B083D20-E19E-486F-A6E8-AD1167CF8E4B@twistedmatrix.com> Message-ID: > On 14 Sep 2016, at 00:28, Glyph Lefkowitz wrote: > > >> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe > wrote: >> >> But this is the framework (non-apple!) build!? > > "framework build" refers to the way that Python is built. Apple's python, Python.org 's python, and Homebrew's python are all framework builds. So, to be clear: this is python.org python? > >> And, again: why isn?t everyone seeing this all the time? (And why didn?t I see it before?) > > There's probably a .pth file somewhere that is stuffing Extras on your sys.path. easy_install (especially older versions) is notorious for creating such things in ways that are hard to inspect for. My usual recommendation at this point is to blow away _everything_ in /Library/Python, ~/Library/Python, ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then reinstall from scratch. (Thanks to SIP you don't need to blow away anything in /System anymore; hooray!) It should be enough to remove ?/Library/Python? from the list of site packages in the non-system install of Python, it is added at the end of setsitepackages() in site.py. This should be done before running any code (particularly the ensurepip tool). That would remove the directory containing the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and user provided stuff. Doing this with the python.org installer requires some care, as it will by default run ensurepip during the installation (but this can be turned off). According to issue 28440 /Library/Python/2.7/site-packages will no longer be treated as a site-packages directory in a future release of 2.7. Ronald > -glyph > _______________________________________________ > 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: From ronaldoussoren at me.com Tue Dec 13 06:22:47 2016 From: ronaldoussoren at me.com (Ronald Oussoren) Date: Tue, 13 Dec 2016 12:22:47 +0100 Subject: [Pythonmac-SIG] Examples of vendoring python 3 with py2app In-Reply-To: References: Message-ID: <502FF4ED-921E-492E-827F-C28EDC6F8DDD@me.com> > On 11 Dec 2016, at 16:22, Cosimo Lupo wrote: > > Hello list, > > Apologies if this is not the right place to ask about this. > > I would like to distribute a self-contained OSX app of an application of mine written in Python 3. I've used py2app in the past to ship apps written in Python 2.7, that linked to the system Python framework. > Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my py2app-generated app. > > In the py2app docs I could not find information as to how to embed the python 3.5 interpreter and stdlib alongside the generated .app bundle. > > Could anyone point me in the right direction, and/or link to existing open source apps that do this? > > Thank you for your help. py2app will do that automatically unless you either explicitly tell it not to, or you use /usr/bin/python (the Apple provided installation of Python). Ronald From pythonchb at gmail.com Tue Dec 13 11:25:56 2016 From: pythonchb at gmail.com (Christopher Barker) Date: Tue, 13 Dec 2016 16:25:56 +0000 Subject: [Pythonmac-SIG] Need help with Python Library link error in OS X 10.11.6 In-Reply-To: References: Message-ID: The configure script should come with the source. It is specific to that particular package, not a system script. But brew should do that for you anyway. I have no idea what Appium is, but it looks like it depends on Python -- you probably neeed to install the brew version of Python first. I would have thought that brew's dependency management would handle that, but it's worth a try to do it by hand. -CHB On Tue, Dec 13, 2016 at 2:28 AM Manohar K Chintala wrote: > Hello Team, > > I am setting up Appium for mobile test automation on new Mac with OS X > 10.11.6 and as part of that I had to run following command. > > brew install --HEAD libimobiledevice > > and following error message was displayed at the end of this command run > > ************************************************************** > > checking consistency of all components of python development > environment... no > configure: error: > Could not link test program to Python. Maybe the main Python library has > been > installed in some non-standard library path. If so, pass it to configure, > via the LDFLAGS environment variable. > Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib" > > ============================================================================ > ERROR! > You probably have to install the development version of the Python > package > for your distribution. The exact name of this package varies among them. > > ============================================================================ > > ******************************************************************* > > I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m" > as suggested however it failed as it couldn't find "configure" in current > user's folder. I also searched in other file system to locate "configure" > but couldn't find it. I need to revolve this Python lib link issue and need > suggestions on how to do it. Things I need help on: > 1. Where can I find "configure" to run the suggested LDFLAGS command. If > it is not available in my Mac, what is the next step for me. > 2. Do I need to install any Python builds to get rid of this error and be > able to run brew install --HEAD libimobiledevice command successfully. > > Thank you > > Regards > Manohar > > > > _______________________________________________ > > 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: From pythonchb at gmail.com Tue Dec 13 11:37:18 2016 From: pythonchb at gmail.com (Christopher Barker) Date: Tue, 13 Dec 2016 16:37:18 +0000 Subject: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra) In-Reply-To: References:

<06E9F64E-FBA4-4909-B1F0-EC58A4A73E7A@twistedmatrix.com> <74585C70-1FC2-4B9C-8A50-DFD12D4275F0@cwi.nl> <3C7A8CDB-388E-4938-A0A6-A6B8BAB6C4AF@gmail.com>

Message-ID: Thank you all for the replies. I've tried using py2app with a framework python 3.5.2 from Python.org and can confirm it correctly bundles everything up in the generated app. I somehow was under the impression that I had to do something special about it, but it turns out it is much easier than I thought! Thanks again :) Cosimo On 13 December 2016 at 16:21, Christopher Barker wrote: > Have tried it? Back in the day, py2app would embed the entire python > runtime if you ran it with a non-Apple python. > > I haven't tried it with py3, but it may "just work" > > You'll know, 'cause you will get a big bundle :-). And you can, of course > look inside and see what's there. > > -CHB > > > On Tue, Dec 13, 2016 at 2:28 AM Cosimo Lupo > wrote: > >> >> >> >> >> >> >> >> >> >> >> Hello list, >> >> >> >> >> >> Apologies if this is not the right place to ask about this. >> >> >> >> >> >> I would like to distribute a self-contained OSX app of an application of >> mine written in Python 3. I've used py2app in the past to ship apps written >> in Python 2.7, that linked to the system Python framework. >> >> >> Now I'm wondering if I could if and how I could "vendor" Python 3.5 >> inside my py2app-generated app. >> >> >> >> >> >> In the py2app docs I could not find information as to how to embed the >> python 3.5 interpreter and stdlib alongside the generated .app bundle. >> >> >> >> >> >> Could anyone point me in the right direction, and/or link to existing >> open source apps that do this? >> >> >> >> >> >> Thank you for your help. >> >> >> >> >> >> -- >> >> >> Cosimo Lupo >> >> >> >> >> >> >> _______________________________________________ >> >> 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: From chris.barker at noaa.gov Tue Dec 13 14:42:51 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Tue, 13 Dec 2016 11:42:51 -0800 Subject: [Pythonmac-SIG] Need help with Python Library link error in OS X 10.11.6 In-Reply-To: References: Message-ID: > brew install --HEAD libimobiledevice > odd -- this: http://brewformulas.org/Libimobiledevice doesn't make it look like it needs Python. I think this is a question for the brew folks. -CHB > and following error message was displayed at the end of this command run > > ************************************************************** > > checking consistency of all components of python development > environment... no > configure: error: > Could not link test program to Python. Maybe the main Python library has > been > installed in some non-standard library path. If so, pass it to configure, > via the LDFLAGS environment variable. > Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib" > =========================================================== > ================= > ERROR! > You probably have to install the development version of the Python > package > for your distribution. The exact name of this package varies among them. > =========================================================== > ================= > > ******************************************************************* > > I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m" > as suggested however it failed as it couldn't find "configure" in current > user's folder. I also searched in other file system to locate "configure" > but couldn't find it. I need to revolve this Python lib link issue and need > suggestions on how to do it. Things I need help on: > 1. Where can I find "configure" to run the suggested LDFLAGS command. If > it is not available in my Mac, what is the next step for me. > 2. Do I need to install any Python builds to get rid of this error and be > able to run brew install --HEAD libimobiledevice command successfully. > > Thank you > > Regards > Manohar > > > _______________________________________________ > 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 > > -- 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: From glyph at twistedmatrix.com Tue Dec 13 14:16:18 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Tue, 13 Dec 2016 11:16:18 -0800 Subject: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra) In-Reply-To: References:

<06E9F64E-FBA4-4909-B1F0-EC58A4A73E7A@twistedmatrix.com> <74585C70-1FC2-4B9C-8A50-DFD12D4275F0@cwi.nl> <3C7A8CDB-388E-4938-A0A6-A6B8BAB6C4AF@gmail.com>

<9B083D20-E19E-486F-A6E8-AD1167CF8E4B@twistedmatrix.com> <50A5DEF7-0281-4849-B0DA-068357F1DA9D@gmail.com> <162AD212-E975-470F-879C-9BC0E2743F86@twistedmatrix.com> <969CB433-74EF-4417-93F3-46470E4E21A2@twistedmatrix.com> <0184dc3a-5bd8-cf0e-fa59-7b60265755eb@gmail.com> <87824946-b86c-8e92-64db-086893ec0443@gmail.com> <0C9C00D8-CF33-4BF3-84A7-6A92C45CD300@twistedmatrix.com> <7BE200AD-4B49-477C-9453-44D0749B9A78@twistedmatrix.com> <70854F44-F61B-43D6-B6E3-EAA45F4EA53B@mac.com> Message-ID: > On 15 Dec 2016, at 21:41, Cosimo Lupo wrote: > > +1 on having the official Python.org distribution be a standalone Python.app that users could just drag-and-drop like with the rest of native non-AppStore apps! A Python.app from python.org should be a long term plan at best, it would be better to start work on this outside of constraints of CPython (e.g. not being able to use libraries outside of the stdlib and only shipping feature updates with major releases). > > (I wish Apple shipped macOS with Python 3?) I?ve mixed feelings about that, on the one hand having Python 3 available by default would be cool, but on the other hand you?d have to rely on Apple to keep that software up to date and Apple tends to only ship security updates between major releases. That?s not too bad for Python 2.7, but is less useful for 3.x. > > And thanks a lot Ronald for the PyObjC wheels on PyPi :D That turned out to be a lot less work than I expected, I should have done the work a long time ago ;-) Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Sun Dec 18 15:39:08 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 18 Dec 2016 21:39:08 +0100 Subject: [Pythonmac-SIG] py2app release delayed Message-ID: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> Hi, I had hoped to release a new version of py2app today, but didn?t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it. I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for ?@loader_path? in shared libraries, which is used in wheels processed with delocate > such as the wheels for Pillow. Because this is turning into a fairly large release I?d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph , https://bitbucket.org/ronaldoussoren/macholib and https://bitbucket.org/ronaldoussoren/py2app ). There?s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point). Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Sun Dec 18 17:39:41 2016 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 18 Dec 2016 14:39:41 -0800 Subject: [Pythonmac-SIG] py2app release delayed In-Reply-To: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> Message-ID: <8B74D63D-3717-44A5-8EC0-FBD9D67FA8F5@twistedmatrix.com> > On Dec 18, 2016, at 12:39 PM, Ronald Oussoren wrote: > > Hi, > > I had hoped to release a new version of py2app today, but didn?t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it. > > I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for ?@loader_path? in shared libraries, which is used in wheels processed with delocate > such as the wheels for Pillow. > > Because this is turning into a fairly large release I?d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph , https://bitbucket.org/ronaldoussoren/macholib and https://bitbucket.org/ronaldoussoren/py2app ). Can you translate these URLs into (pinned) URLs suitable for a requirements.txt? I'm not used to doing this with hg or bitbucket. If so I'd be happy to test with Mimic. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at barrys-emacs.org Tue Dec 20 18:02:48 2016 From: barry at barrys-emacs.org (Barry Scott) Date: Tue, 20 Dec 2016 23:02:48 +0000 Subject: [Pythonmac-SIG] py2app release delayed In-Reply-To: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> Message-ID: <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> > On 18 Dec 2016, at 20:39, Ronald Oussoren wrote: > > Hi, > > I had hoped to release a new version of py2app today, but didn?t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it. > > I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for ?@loader_path? in shared libraries, which is used in wheels processed with delocate > such as the wheels for Pillow. > > Because this is turning into a fairly large release I?d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph , https://bitbucket.org/ronaldoussoren/macholib and https://bitbucket.org/ronaldoussoren/py2app ). > > There?s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point). > Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app. I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds. I?m using py2app to package a couple of apps that use PyQt and pytz. I found that the resulting app has the .dylib files in the python35.zip. Is that correct? I had assumed that .dylib files need to be in the .app as files, is there a trick to run them out of the .zip file? I have been copying in the PyQt .dylib, plugins etc into the .app with a script that adds these in Contents/Frameworks etc after fixing up the RPATHs. For pytz to work in a py2app .app pkg_resources needs to work and it does not. Is this a known issue? I worked around it with a stub pkg_resources package that reached into the python35.zip and pulled out the zoneinfo files. It seems that py2app will package up all the files in a package, not just the .py files. Is that the algorithm that is used? > Ronald > _______________________________________________ > 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: From ronaldoussoren at mac.com Tue Dec 27 14:36:13 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 27 Dec 2016 20:36:13 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> Message-ID: > On 21 Dec 2016, at 00:02, Barry Scott wrote: > >> >> On 18 Dec 2016, at 20:39, Ronald Oussoren > wrote: >> >> Hi, >> >> I had hoped to release a new version of py2app today, but didn?t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it. >> >> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for ?@loader_path? in shared libraries, which is used in wheels processed with delocate > such as the wheels for Pillow. >> >> Because this is turning into a fairly large release I?d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph , https://bitbucket.org/ronaldoussoren/macholib and https://bitbucket.org/ronaldoussoren/py2app ). >> >> There?s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point). >> > > Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app. > I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds. > > I?m using py2app to package a couple of apps that use PyQt and pytz. > > I found that the resulting app has the .dylib files in the python35.zip. > Is that correct? I had assumed that .dylib files need to be in the .app > as files, is there a trick to run them out of the .zip file? That?s not supposed to happen. Are the dylibs part of a python package? If so, are these loaded by C extensions or included as data files (for example because ctypes is used to load the dylib)? A bug report on bitbucket with a sample project that demonstrates the problem would be appraised. I cannot promise that I?ll promptly fix the issue, but a sample project would make fixing this a lot easier. As an aside to this: I?m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles. > > I have been copying in the PyQt .dylib, plugins etc into the .app with > a script that adds these in Contents/Frameworks etc after fixing up the RPATHs. > > For pytz to work in a py2app .app pkg_resources needs to work and it > does not. Is this a known issue? I worked around it with a stub pkg_resources > package that reached into the python35.zip and pulled out the zoneinfo files. I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven?t gotten around to doing the work for that because I don?t need the feature myself. AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app?s tracker? > > It seems that py2app will package up all the files in a package, not just the > .py files. Is that the algorithm that is used? That?s correct. All files in the directory of a python package are assumed to be important. BTW. None of these fixes will be in the next release of py2app, but I really hope to find a way to do more py2app maintenance next year (instead of basically just doing so during vacations). Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue Dec 27 16:38:22 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Tue, 27 Dec 2016 13:38:22 -0800 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> Message-ID: On Tue, Dec 27, 2016 at 11:36 AM, Ronald Oussoren wrote: > As an aside to this: I?m considering to remove the site-packages.zip file > from the app bundle and store everything outside off zipfiles. A lot of > code works inside zipfiles, but there are too many exceptions and with the > transition from eggs to wheels even less packages will care to document > whether or not they work with their code in zipfiles. > I think this is a good idea -- these days, size really only matters when you're shipping the app, not when it's on disk (or SSD) -- so why bother with the zip? > I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven?t gotten around to doing the work for that because I don?t need the feature myself. > > AFAIK pkg_resources should work for accessing datafiles though. Could you > file a bug for the pytz problem on py2app?s tracker? > pkg_resources is a pain in general, and particularly always has been with py2app and the like. but I've usually gotten it to work OK by explicitly listing the package to be included, so that py2app will bundle the whole thing. > It seems that py2app will package up all the files in a package, not just > the > .py files. Is that the algorithm that is used? > > > That?s correct. All files in the directory of a python package are assumed > to be important. > which is why it usually works OK for things like pytz. :-( -CHB -- 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: From ronaldoussoren at mac.com Wed Dec 28 04:11:04 2016 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Dec 2016 10:11:04 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> Message-ID: <798FD8FC-A780-4704-8FE9-396595D0F348@mac.com> An HTML attachment was scrubbed... URL: From barry at barrys-emacs.org Wed Dec 28 14:24:43 2016 From: barry at barrys-emacs.org (Barry Scott) Date: Wed, 28 Dec 2016 19:24:43 +0000 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> Message-ID: > On 27 Dec 2016, at 19:36, Ronald Oussoren wrote: > > >> On 21 Dec 2016, at 00:02, Barry Scott > wrote: >> >>> >>> On 18 Dec 2016, at 20:39, Ronald Oussoren > wrote: >>> >>> Hi, >>> >>> I had hoped to release a new version of py2app today, but didn?t due to problems with macholib that resulted in broken application bundles. The good news is that I found the cause of that breakage and reverted the patch that caused it. >>> >>> I did fix a number of bugs on the tracker last week (the number of open issues decreased from 94 to 72), and implemented a useful new feature: support for ?@loader_path? in shared libraries, which is used in wheels processed with delocate > such as the wheels for Pillow. >>> >>> Because this is turning into a fairly large release I?d appreciate if people could test the code in the repository with their applications. To install first install altgraph-0.13, then install modulegraph, macholib and py2app from their bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph , https://bitbucket.org/ronaldoussoren/macholib and https://bitbucket.org/ronaldoussoren/py2app ). >>> >>> There?s still a fairly large number of open issues for py2app, but those will have to wait for a later time (which hopefully be a lot sooner than the time it took me to get from the previous release to this point). >>> >> >> Thanks for working on an update. I know you time is limited, however I hope you can comment on these questions about py2app. >> I was looking at contributing patches but found, as you did that macholib was very broken so gave up patching and hacked workarounds. >> >> I?m using py2app to package a couple of apps that use PyQt and pytz. >> >> I found that the resulting app has the .dylib files in the python35.zip. >> Is that correct? I had assumed that .dylib files need to be in the .app >> as files, is there a trick to run them out of the .zip file? > > That?s not supposed to happen. Are the dylibs part of a python package? If so, are these loaded by C extensions or included as data files (for example because ctypes is used to load the dylib)? > > A bug report on bitbucket with a sample project that demonstrates the problem would be appraised. I cannot promise that I?ll promptly fix the issue, but a sample project would make fixing this a lot easier. Will do. It looks like for PyQt5 you put the .so files you find in to the app ion Contents/Resources/lib/python3.5/lib-dynload/PyQt5/Qt.so etc. But PyQt5 will not work without a lot of other files from the packager also being files on disk. They are all in the python35.zip. > > As an aside to this: I?m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles. If you dropped the ZIP, or a option to not use it, then this bug wold be fixed. Otherwise I have to tell py2app that PyQt5 must be on disk not in ZIP. >> >> I have been copying in the PyQt .dylib, plugins etc into the .app with >> a script that adds these in Contents/Frameworks etc after fixing up the RPATHs. >> >> For pytz to work in a py2app .app pkg_resources needs to work and it >> does not. Is this a known issue? I worked around it with a stub pkg_resources >> package that reached into the python35.zip and pulled out the zoneinfo files. > > I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven?t gotten around to doing the work for that because I don?t need the feature myself. > > AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app?s tracker? > I also see pkg_resources broken and ship a workaround: https://github.com/barry-scott/scm-workbench/blob/master/Source/Common/wb_date.py >> >> It seems that py2app will package up all the files in a package, not just the >> .py files. Is that the algorithm that is used? > > That?s correct. All files in the directory of a python package are assumed to be important. > > BTW. None of these fixes will be in the next release of py2app, but I really hope to find a way to do more py2app maintenance next year (instead of basically just doing so during vacations). I guess all the py2app related repo?s are working now. (You fixed a show stopper in macho lib recently). I?ll look to shipping you patches with the bug reports. I have experience with type of python packaging software, but for Linux and windows. Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: