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