[Pythonmac-SIG] PyObjC 3.2 released

Wed Dec 7 03:21:38 EST 2016

> On 7 Dec 2016, at 00:28, Glyph Lefkowitz <glyph at twistedmatrix.com> 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 <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> wrote:
>> 
>>> 
>>> On 6 Dec 2016, at 21:43, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
>>> 
>>>> 
>>>> On Dec 6, 2016, at 12:17 PM, Ronald Oussoren <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> wrote:
>>>> 
>>>>> 
>>>>> On 6 Dec 2016, at 20:30, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at twistedmatrix.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>> 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 <https://bitbucket.org/ronaldoussoren/pyobjc/src/3e6dce3dcfa0a3a72f9a204855d83644eaf6afc0/development-support/upload-release?at=default&fileviewer=file-view-default <https://bitbucket.org/ronaldoussoren/pyobjc/src/3e6dce3dcfa0a3a72f9a204855d83644eaf6afc0/development-support/upload-release?at=default&fileviewer=file-view-default>>).  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 <http://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 <http://python.org/> binaries you can use “arch -i386 python” to select the 32-bit binary.

There are two installers on python.org <http://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 <http://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: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161207/2197cd32/attachment.html>