[Pythonmac-SIG] PyObjC 3.2 released

[Glyph Lefkowitz]

> On Dec 6, 2016, at 12:17 PM, Ronald Oussoren <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.

> 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: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161206/e6c0d65e/attachment-0001.html>