> On Dec 6, 2016, at 12:17 PM, Ronald Oussoren <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.
> 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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
