> On 7 Dec 2016, at 00:28, Glyph Lefkowitz <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.
Ronald
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
