> On 6 Dec 2016, at 20:30, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > >> On Dec 6, 2016, at 10:36 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote: >> >> >>> On 6 Dec 2016, at 19:19, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: >>> >>> >>>> On Dec 6, 2016, at 8:59 AM, Ronald Oussoren <ronaldousso...@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. 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 >
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
