[Pythonmac-SIG] [ANN] PyObjC 10.0 released

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve tagged PyObjC 10.0 and am in the process of uploading to PyPI.

The major change in this version is support for macOS Sonoma, just in time for 
the release of that version of macOS. 

Some other changes:
* The lazy loading machinery no longer uses  “objc.ObjCLazyModule”
* Python 3.7 is no longer supported 
* objc.simd was restructured, hopefully without impact on user code 

See the full changelog of 
https://pyobjc.readthedocs.io/en/latest/changelog.html for a detailed list of 
changes.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Mastodon: @ron...@blog.ronaldoussoren.net.
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] PyObjC 9.1b1

[Ronald Oussoren via Pythonmac-SIG]

PyObjC 9.1 is one of the rare times that I'm publishing explicit beta releases. 
PyObjC 9.1b1 is available on PyPI ("pip install pyobjc-9.1b1").

This release contains the usual SDK updates (macOS 13.3) and minor bugfixes, 
but more importantly it contains some major changes to pyobjc-core.  Because of 
this I kindly request that you test this beta release and let me know about any 
problems.

First of all the code that transforms class attributes, and in particular 
translates Python functions to “objc.selector" objects, was rewritten from C to 
Python.  This change should be transparant for users, other than some error 
cases and intentation changes:

1. The new code is smarter about recognizing if a method is intended to be used 
as an Objetive-C selector and will not translate multi-word PEP8 compatable 
names (e.g. "my_,method"). This reduces the need to use the python_selector 
decorator.

2. Coroutings (async methods, iterators) are no longer translated to a selector

3. The new code will translate *all* callables, which may lead to needing to 
use the python_method decorator in some cases (e.g. when using a builtin 
function as a class attribute)

4. It is now possible to use varargs in a selector method when the implied 
number or arguments can be represented.

Furthermore the “python_method" and “informal_protocol" classes are now 
implemented in Python instead of Objective-C. Those should have no user-visible 
changes in behaviour.

Lastly a number of classes are now created using “PyType_FromSpec" instead of 
using static “PyTypeObject" definitions. That results in minor change in 
behaviour when using Python 3.9 or earlier: In those versions it is not 
possible to make these classes immutable. Don't rely on this behaviour.

As always the full changelog can be seen at 
. 

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Mastodon: @ron...@blog.ronaldoussoren.net.
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Supplying Unicode strings to pyobjc

[Ronald Oussoren via Pythonmac-SIG]

> On 10 Apr 2022, at 09:23, Ben Byram-Wigfield via Pythonmac-SIG 
>  wrote:
> 
> I'm converting a lot of python2 scripts that use pyobjc to python3, and 
> having trouble getting them to work. The problem seems to relate to the 
> Unicode changes in python3.
> 
> Something as simple as supplying a string to method like this:
> 
> provider = CGDataProviderCreateWithFilename(filename)
> 
> gives: ValueError: depythonifying 'char', got 'str' of 1
> 
> I can get it to work if I encode the string first:
> 
> filenameNonU = filename.encode('utf-8')
> provider = CGDataProviderCreateWithFilename(filenameNonU)

This is the correct code pattern.  PyObjC is a bit more strict here when 
running on Python 3: The C argument is a C string, which is represented as a 
bytes value in Python. In Python 2 the code also accepted unicode (str in 
Python 3), I removed that because Python 3 treats str and bytes differently.

> 
> But that will only work for “ASCII” range characters. Any characters greater 
> than 128 gives:
> 
> ValueError: depythonifying 'char', got 'int' of wrong magnitude

That’s unexpected, could you file an issue about this on the PyObjC tracker?

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)

[Ronald Oussoren via Pythonmac-SIG]

> On 16 Dec 2021, at 20:21, Chris Barker via Pythonmac-SIG 
>  wrote:
> 
> I've just got a new mac with OS-X 11.6 (still Intel).
> 
> But when I try to run a PyInstaller built application, I get this error:
> 
> No document available for {'mime': 'application/x-maproom-project-zip', 
> 'loader':  0x7f9669ce6e10>, 'uri': 'template://default_project.maproom'}
> 
> And the app won't start.
> 
> This has worked just fine on numerous previous OS-X versions.
> 
> I have the source code, but the developer that built it is no longer with us, 
> so it'll take b e a bit to get up to speed, and I don't even know where to 
> start! Is this a PyInstaller issue? or a code issue, or ???
> 
> Hints:
> 
> The application is called MapRoom (maproom) it works with "projects" that are 
> essentially a zip file with all the info required in it.
> 
> I think, on startup, it loads a empty default project, presumably 
> "default_project.maproom"
> 
> So I think that's where the app startup code is barfing, not having the mime 
> type registered properly. But where / how am I supposed to do that?
> 
> or maybe it's not a mime type registration issue, but simply that the 
> template can't be found -- so a path issue in the App bundle??
> 
> Anyway, I'll be digging into this deeper in the source code, but if anyone 
> has seen anything like this, any hints would be appreciated!

I’m afraid you’ll have to dig in.   The error message seems to indicate that 
mime type itself works, there is a (non-standard) mime type in the error 
message.

Does running the application from the terminal give you more clues?

How is the application normally installed, it is just an app or does it use an 
installer that may install more files? I’ve had issues in the past when copying 
an app bundle to a new machine and forgetting to copy some resource files that 
weren’t in the app bundle.

Ronald

> 
> Thanks,
> 
> -CHB
> 
> 
> 
> 
> 
> 
> 
>  
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 8.0

[Ronald Oussoren via Pythonmac-SIG]

A new macOS release means a new major release of PyObjC. I'm happy to announce 
that PyObjC 8 is available on PyPI with full support for macOS 12, including 
APIs introduced in that release.

I've also been working on performance and code quality of the core bridge. 
There are significant speedups of the core bridge in PyObjC 8.0, and I have 
more ideas to reduce the performance difference between regular Python methods 
and calling Objective-C APIs.

The release is a bit later than I would have liked, in part because I've been 
worrying about the covid-19 situation in Holland. Because of that I've spend 
some more time away from the computer.

A full change log is included below.

Backward incompatible changes
In PyObjC 7 and earlier it was possible to leave out "output" arguments when 
calling a method with a Python implementation:

class MyClass(NSObject):
@objc.typedSelector(b"@@:o^@")
def methodWithOutput_(self, a):
return 1, 2

o = MyClass.alloc().init()
print(o.methodWithOutput_())
This no longer works, it is always necessary to pass in all arguments, which 
was already true for methods implemented in Objective-C. That is:

print(o.methodWithOutput_(None))
This change both simplifies the PyObjC code base and was required to cleanly 
implement vectorcall support (see the section on performance below).

Removed bindings for InterfaceBuilderKit. This was a way to integrate with 
InterfaceBuilder in old versions of Xcode, but support for that was dropped 
before the release of Mac OS X 10.8.

Bindings for the Objective-C runtime API related to "associated objects" is now 
enabled unconditionally. This will cause problems when running or building on 
macOS 10.6 or earlier.

It is no longer possible to deploy to macOS 10.7 or earlier when you attempt to 
create a formal protocol. Protocol creation already failed on those platform 
due to lack of the required runtime API, and that will now result in a crash 
because PyObjC no longer checks for availability of that runtime API.

GH-371: Remove manual bindings for a number of old CoreGraphics APIs

The following functions are no longer available:

CGDataProviderCreate
CGDataProviderCreateDirectAccess
These functions were removed as a public API in macOS 10.8, but were still 
available through PyObjC through old backward compatibility code. That code has 
now been removed.

For compatibility with Python's socket APIs functions that return a "struct 
sockaddr" (either by reference or as a function result) will now encode the IP 
address as a string and not a bytes object.

The (undocumented) API in pyobjc-api.h (used in some framework bindings to 
integratie with pyobjc-core) has changed in an incompatible way, in particular 
the API for "caller" functions now mostly mirrors the vectorcall convention.

Adding a method with a double underscore name will now raise an exception at 
class definition time instead of silently not creating the Objective-C method.

 class AClass (NSObject):
 ...

 def __foo_bar__(self, a, b, c):
 pass

 MethodNamesClass.__foo_bar__ = __foo_bar__
Before PyObjC 8 this would add a __foo_bar__ selector to the Python 
representation of the class without adding a selector to the Objective-C class.

Use objc.python_method to mark this as a python-only function.

Upcoming incompatible changes
The module PyObjCTools.Signals is deprecated and will be removed in PyObjC 9.

objc.initFrameworkWrapper and objc.parseBridgeSupport are deprecated and will 
be removed in PyObjC 9.

These functions implement support for ".bridgesupport" XML files, something 
that PyObjC hasn't used itself in a number of releases (in part because system 
versions of those files are at best incomplete).

Performance
Most performance changes use features introduced in Python 3.9, performance in 
older Python versions is unchanged except for the effects of general cleanup.

Implement the "vectorcall" protocol for objc.function, objc.WeakRef, 
objc.selector, objc.IMP, objc.python_method.

This reduces the interpreter overhead for calling instances of these objects.

Implement Py_TPFLAGS_METHOD_DESCRIPTOR for objc.selector, objc.python_method.

Use vectorcall in the method stub that forwards Objective-C calls to Python.

Convert internal calls into Python to the vectorcall protocol (pyobjc-core)

Add more optimized vectorcall implementation to :class:objc.function, objc.IMP 
and objc.selector for simpler callables.

"Simpler" methods are those with a small number of plain arguments, although 
the definition of what's simple will evolve over time.

Generic Implementation Quality
GH-391: Fix some spelling errors found by the codespell 
 tool.

The codespell tool is also run as part of pre-commit hooks.

GH-296: use clang-format for Objective-C code

The Objective-C code for the various extensions has been reformatted using 
clang-format, and this enforced by a pre-commit hook.

GH-374: Use pyupgrade to modernize the 

[Pythonmac-SIG] [ANN] py2app 0.26

[Ronald Oussoren via Pythonmac-SIG]

I've spend some more time on py2app over the last week or so, in between 
relaxing while being away from work. That results in a larger release for 
py2app than I've done in a long while. 

The most important changes are support for Python 3.10 and (finally!) bundling 
package metadata ("dist-info" directories). The latter should fix issues with 
code that uses pkg_resources and looks for distribution information such as 
entry points. 

As always: Py2app is supposed to be a "DWIM" tool, please file issues when you 
need to adjust the bundled application, either through py2app options or 
(especially) manually. 

And a public service announcement: Don't use the "argv_emulator" option with 
GUI applications. That option tends to cause options with GUI eventloops, and 
most GUI libraries have better options to handle "file-open" events.

I expect to work less on py2app in the coming weeks, the current plan is to 
continue working on PyObjC during my last week of from work. The current 
repository is up-to-date w.r.t. support for the upcoming macOS Monterey, and I 
hope to land land some interesting other improvements during the week...

The full changelog:

Stub executables were recompiled on macOS 11

This means support for light mode/dark mode should now work out of the box.

The old stub executables are still used when detecting that Tkinter is used 
with an old build of Tk.

Issue 1: Include ".egg-info" and ".dist-info" information in the bundled 
application

This fixes any python package that uses pkg_resources to look for specific 
distributions.

py2app.filters.not_stdlib_filter now knows about Python's "venv"

Issue 368: Add recipe detect_dunder_file

This recipe will ensure that a Python package is stored outside of 
site-packages.zip when a module in that package uses the __file__ variable.

This variable is most commonly used to load resources stored in the package 
(instead of the newer importlib.resources and pkg_resources libraries).

Issue 339: Add recipe for pydantic

The recipe is needed because pydantic uses Cython to compile all sources 
(including the package __init__) and therefore hides imports from the 
dependency analyzer.

Issue 338: Add "imageio_ffmpeg" to autopackages

PR367: Add recipes for pandas, pylsp, and zmq

PR367: Add docutils and pylint to autopackages

PR by Ryan Clary (mrclary on GitHub)

Issue 344: Invocation of codesign on the whole bundle sometimes fails

Py2app will now try this a number of times before giving up. This is at best a 
workaround for and doesn't completely fix the problem.

Issue 370: py2app now works with Python 3.10

Python 3.10 no longer exports a (private) symbol used by the py2app stub 
executable. Switched to a public API to accomplish the same task where 
available.

Issue 110: Add recipe for SQLAlchemy

The recipe includes all dialects and connectors, including implicit 
dependencies, because SQLAlchemy uses __import__ to load dependencies.

Issue 328: Add recipe for gcloud

Issue 195: Add USER_BASE, getuserbase() and getusersitepackages() to py2app's 
version of site.py.

Issue 184: Add recipe for 'ssl'

This recipe is only used for Python 3.4 or later and ensures that the CA bundle 
used by Python's ssl module is included in the app bundle and OpenSSL is 
configured to look for that bundle in the application bundle.

Issue 371: change default error message on launch problems

The default error message shown when the application cannot be launched is now 
slightly more useful and refers the py2app debug page 
.

Issue 345, 169: Adjust qt5 and qt6 recipes for non-PyPI installations

The qt5 and qt6 recipes now should work when the Qt installation prefix is 
outside of the PyQt package, for example when PyQt was installed through 
homebrew.

I've tested this for PyQt5 and made the same change to the PyQt6 recipe, 
although I haven't tested that change.


—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app and pyinstaller on Big Sur

[Ronald Oussoren via Pythonmac-SIG]

> On 20 May 2021, at 15:26, Paul Fishback  wrote:
> 
> Hello,
> 
> I'm using Python 3.9 on a Mac running Big Sur and have encountered problems 
> converting GUIs into Mac apps. I'm concerned that the problems may arise from 
> Big Sur itself. 
> 
> Pyinstaller: I posted a problem I ran into at 
> https://stackoverflow.com/questions/67593376/pyinstaller-tkinter-script-works-fine-but-wont-execute-properly-as-app-or-uni?noredirect=1#comment119476414_67593376
>  
> .
>  In essence, I created my .app, which did not function on Big Sur but did 
> when someone else ran it on linux. 
> 
> py2app:  Problem I encountered is posted at 
> https://stackoverflow.com/questions/67611680/problem-with-py2app-when-figurecanvastkagg-is-used-in-script?noredirect=1#comment119507494_67611680
>  
> .
>  Essentially, I can get py2app to work fine with a tkinter GUI that utilizes 
> matplotlib, unless I need to import FigureCanvassTkAgg from 
> matplotlib.backends.backend_tkagg. This problem could be more likely due to 
> an incomplete understanding of how to incorporate options with py2app.

I’ve added a comment on the stack overflow question.  It says:

The first step to debug issues like this is to start the application in the 
terminal, that is for MyApp.app run "dist/MyApp.app/Contents/MacOS/MyApp". This 
will print errors to the terminal instead of that they'll be swallowed by the 
system. This will likely print that some module or library cannot be found. You 
can use "includes" (modules) or "packages' (packages) to explicitly include 
those missing modules/packages (but please report back, I can automate this in 
py2app).

Ronald
> 
> Thanks
> 
> PaulF.
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] "pythonw" in a Unix build

[Ronald Oussoren via Pythonmac-SIG]

> On 18 Jan 2021, at 18:38, Christopher Barker  wrote:
> 
> On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren  <mailto:ronaldousso...@mac.com>> wrote:
> As mentioned on python-dev adding the “pythonw” functionality to the unix 
> build is not very hard. I expect that integrating with the build system 
> (Makefile/configure script) will be the hardest part due to introducing 
> different behaviour for the macOS platform. 
> 
> Thanks Ronald, that confirms my suspicions that this is really an autoconf 
> issue. Which makes it an utter mystery to me :-(

Most of the relevant build machinery is in the Makefile. And looking at this 
there’s already precedent for checking for macOS there, “python-config” is a 
shell script on all platforms except macOS, and the makefile fragment for 
building it checks if we’re on macOS without using autoconf.

>> And we already have a work around in the core python code, it's just that 
>> the build system needs to be set up to build it outside of a Framework.
> The framework build does not have a workaround for these problems, it has a 
> proper solution ;-). 
> 
> Glad to hear that -- in earlier conversations, I got the impression that you 
> thought the executable wrapper was kind of a hack :-).

In the end it is a workaround for a platform feature that’s causing problems, 
but Python.app in the framework build is a proper app bundle.  Using a shell 
script for the same functionality is a hack (he says without having looked at 
that script) ;-)

> 
> Anyway -- if any of you have autoconf expertise and the inclination, I'd love 
> to see this get done, and would be glad to help as best I can.
> 
> -CHB
>  
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython


Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] "pythonw" in a Unix build

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Jan 2021, at 06:24, Christopher Barker  wrote:
> 
> On Thu, Jan 14, 2021 at 3:14 PM Jack Jansen  > wrote:
> For example, the brew Python is installed into a framework tucked away deep 
> in /usr/local/Cellar but you don’t notice this at all: you can just use 
> “python foo.py” and the moment the script does GUI calls it’ll get an icon in 
> the doc and all that.
> 
> What problem are you trying to solve?
> 
> It's interesting that brew python has decided to use a Framework build 
> 
> But the problem at hand is conda python which used a plain unix build.

Maybe they should switch to a framework build instead :-)

> 
> They have provided a shell script "pythonw" that re-directs to a python 
> inside an app bundle, and that works OK on the command line, but it does not 
> work with, e.g. setuptools entry points.
> 
> I could dig up the threads, but this has been discussed on this list, and few 
> gitHub issues. 

As mentioned on python-dev adding the “pythonw” functionality to the unix build 
is not very hard. I expect that integrating with the build system 
(Makefile/configure script) will be the hardest part due to introducing 
different behaviour for the macOS platform. 

> 
> In short, there are a few ways to work around these issues, but no one (the 
> conda people, the setuptools devs) wants to put the kludgy work around in 
> their code.
> 
> And we already have a work around in the core python code, it's just that the 
> build system needs to be set up to build it outside of a Framework.

The framework build does not have a workaround for these problems, it has a 
proper solution ;-). 

Ronald

> 
> -CHB
> 
> 
>  
> Jack
> 
>> On  14-Jan-2021, at 23:07 , Chris Barker via Pythonmac-SIG 
>> mailto:pythonmac-sig@python.org>> wrote:
>> 
>> Ned suggested I bring this conversation over here from python-dev, so here 
>> it is.
>> 
>> What I'd like to see done is have the "pythonw" wrapper buildable in an 
>> otherwise non-framework build.
>> 
>> I *think* there are no real technical show stoppers, but it would take some 
>> auto-conf magic, which I am fully unqualified to take on.
>> 
>> Anyone interested in helping make this happen ?
>> 
>> -CHB
>> 
>> 
>> -- 
>> 
>> Christopher Barker, Ph.D.
>> Oceanographer
>> 
>> Emergency Response Division
>> NOAA/NOS/OR(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>> 
>> chris.bar...@noaa.gov 
>> ___
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
>> 
>> https://mail.python.org/mailman/listinfo/pythonmac-sig 
>> 
>> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
>> 
> 
> --
> Jack Jansen, mailto:jack.jan...@cwi.nl>>, 
> http://www.cwi.nl/~jack 
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
> 
> https://mail.python.org/mailman/listinfo/pythonmac-sig 
> 
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
> 
> 
> 
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
> 
> https://mail.python.org/mailman/listinfo/pythonmac-sig 
> 
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
> 
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] py2app 0.23

[Ronald Oussoren via Pythonmac-SIG]

Hi,

Py2app 0.23 is on PyPI. There are two noteworthy changes:

* Support building “Universal 2” applications when using a “universal2” build 
of Python

* Proces “@loader_path” in shared libraries, which should improve building apps 
based on wheels on PyPI that were build with the “delocate” tool

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 7.1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve uploaded PyObjC 7.1 to PyPI. The most important change is support for 
API’s introduced in macOS 11.1. Other than that there was a change to make it 
easier to build with the Command Line Tools instead of Xcode (for those not 
using the binary wheels).

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app questions

[Ronald Oussoren via Pythonmac-SIG]

> On 13 Dec 2020, at 04:53, Timothy M. Shead  
> wrote:
> 
> Many thanks for py2app, of all the packaging apps I’ve tried, it’s been the 
> most usable by far; that said, I have questions.  Using conda, python 3.8.5, 
> and py2app 0.22 on MacOS 10.15.7 with the following test app:
> 
># hello.py
>print(“Hello, World!”)
> 
> And the following default setup.py:
> 
>from setuptools import setup
> 
>APP = ["hello.py”]
>DATA_FILES = []
>OPTIONS = {}
> 
>setup(
>app=APP,
>data_files=DATA_FILES,
>options={"py2app": OPTIONS},
>setup_requires=["py2app”],
>)
> 
> Everything builds and runs fine:
> 
>$ python setup.py py2app
>$ dist/hello.app/Contents/MacOS/hello
>Hello, World!
> 
> However, upon closer inspection, I see that there are a couple of libs that 
> are being loaded from outside the bundle:
> 
>$ DYLD_PRINT_LIBRARIES=1 dist/hello.app/Contents/MacOS/hello
>...
>/Users/tshead/miniconda3/envs/flow/lib/libz.1.dylib
>/Users/tshead/miniconda3/envs/flow/lib/libffi.7.dylib
> 
> Focusing on libz, I see that it’s being loaded from a library that is part of 
> the bundle:
> 
>$ otool -L 
> dist/hello.app/Contents/Resources/lib/python3.8/lib-dynload/zlib.so
>dist/hello.app/Contents/Resources/lib/python3.8/lib-dynload/zlib.so:
>   @rpath/libz.1.dylib (compatibility version 1.0.0, current version 
> 1.2.11)
>…

How was Python build? 

> 
> And when I look at the main executable, the second rpath looks questionable:
> 
>$ otool -l dist/hello.app/Contents/MacOS/hello
>…
>Load command 16
>  cmd LC_RPATH
>  cmdsize 32
> path @loader_path/../lib (offset 12)
>Load command 17
>  cmd LC_RPATH
>  cmdsize 48
> path @loader_path/../../../../../ (offset 12)

Was this file created by py2app, or did you change it afterwards?  The stub 
executable in current releases of py2app should not contain LC_RPATH entries at 
all.

> 
> What is the right approach to address this?  Manually copy the missing .dylib 
> files into dist/hello.app/Contents/lib?  I’m too new to know what to expect 
> from py2app, but I’m surprised that it would be necessary for something as 
> ubiquitous as zlib?

Py2app, or rather the macholib library used by py2app, does not process @rpath 
correctly. The code is older than the introduction of this feature and is not 
easily adjusted for it because some information needed for correctly dealing 
with @rpath and @loader_path is lost before the code that should use the 
information is active.  I have rewriting that code on my too long todo list.

Note that this works for me, with the Python.org  
installation of Python.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> 
> Cheers,
> Tim
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 7.0.1

[Ronald Oussoren via Pythonmac-SIG]

I’ve uploaded PyObjC 7.0.1 to PyPI, because the 7.0 release didn’t build on 
platforms other than Big Sur :-(

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 7.0

[Ronald Oussoren via Pythonmac-SIG]

Finally A bit later than I had expected I've uploaded PyObjC 7.0 to PyPI. 

This release includes support for new APIs introduced in macOS 11 (Big Sur), as 
well as support for arm64. 

The binary wheels on PyPI are only for x86_64 for now, I'll add "universal2" 
wheels once I've resolved some issues with the packaging ecosystem. 

The release was cut from the branch "pyobjc-7-branch". Because of this the 
website has not been updated.

Changelog

Added support for arm64 (aka "Apple Silicon")

Existing framework bindings were updated for the macOS 11.0 SDK

Added bindings for the following frameworks:

Accessibility (introduced in macOS 11.0)
AppTrackingTransparency (introduced in macOS 11.0)
CallKit (introduced in macOS 11.0)
ClassKit (introduced in macOS 11.0)
KernelManagement (introduced in macOS 11.0)
MetalPerformanceShaders (introduced in macOS 10.13)
MetalPerformanceShadersGraph (introduced in macOS 11.0)
MLCompute (introduced in macOS 11.0)
PassKit (introduced in macOS 11.0)
ReplayKit (introduced in macOS 11.0)
ScreenTime (introduced in macOS 11.0)
UniformTypeIdentifiers (introduced in macOS 11.0)
UserNotificationsUI (introduced in macOS 11.0)
Virtualization (introduced in macOS 11.0)
Dropped the bindings to the QTKit framework. This framework was removed in 
macOS 10.15.

Dropped the bindings for the XgridFoundation framework. This framework was 
removed in macOS 10.8.

This version drops support for 32-bit executables, both the core bridge and the 
framework wrappers only support 64-bit executables going forward

PyObjC is now always build with the system libffi.

issue 301: pyobjc-framework-Metal build failed on macOS mojave

Python 3.10 support: Don't assume the result of PyREFCNT, PySIZE and Py_TYPE 
are an lvalue.

Python 3.10 support: Completely phase out use of old buffer API, which will be 
removed in Python 3.10. As a side effect of this a number of extensions that 
used the limited ABI once again use the regular ABI.

Removed remnants of support for i386, ppc and ppc64 from pyobjc-core.

Added type to manage Py_buffer lifetimes to the internal API in pyobjc-core, to 
be used by framework wrappers.

Add objc._C_BYREF. This definition was missing, but isn't used in modern ObjC 
code.

PR 323: Remove leading slashes from detected SDK patch to avoid miscalculating 
the version. Patch by GitHub user linuxfood.

PR 322: Avoid None error in PyObjCTools.AppHelper. Patch by github user mintho

PR 321: Fix typo in documentation. Patch by github user russeldavis

A personal note

The changelog is fairly long, but shorter than I had hoped after WWDC. I've had 
a hard time to find the energy to spent a lot of time on PyObjC in the current 
state of the world. I've been working from home since March, and even now video 
meetings are pretty draining. It also doesn't help that my main hobby away from 
the computer is a full contact sport that's on hold for most of that time 
without a clear indication on when that will change (and when I'll feel 
comfortable with this). 

On a more positive note: A different distraction from my own projects is 
working on CPython again, in particular working with Ned Deily and Lawrence 
D'Anna on supporting arm64 and "Universal 2" to CPython. The first visible 
result of that is an experimental "Univeral 2" build of the upcoming Python 
3.9.1 release.


Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Can't complete py2app build

[Ronald Oussoren via Pythonmac-SIG]

> On 27 Sep 2020, at 09:18, The Shelter via Pythonmac-SIG 
>  wrote:
> 
> 
> I myself switched after much trouble w/ py2app on Python3. 

Did you file issues about those?

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Can't complete py2app build

[Ronald Oussoren via Pythonmac-SIG]

> On 16 Sep 2020, at 21:56, Terry Acree via Pythonmac-SIG 
>  wrote:
> 
> Sorry to bother you but i can’t get py2app to complete. all packages up to 
> date py2app 0.22.
> 
> error
> raise ValueError("%r does not exist" % (pathname,))
> ValueError: '/opt/anaconda3/lib/libpython3.7.dylib' does not exist

I don’t use Anaconda myself, so can’t easily test. Does this file exist on your 
system? 

The error happens because some library or Python extension refers to this 
library in the
dependencies in its Mach-O binary header.

Ronald


—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] py2app 0.22

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve uploaded py2app 0.22 to PyPI. This contains a small number of bug fixes, 
most important of which was an problem when deploying to macOS 10.9 or 10.10. 


* #300: Add support for ARM64 and Universal 2 binaries

  NOTE: Support is highly experimental, these stubs have not been tested yet.

* #299: Fix build error when building with the copy of Python 3 shipped
  with Xcode.

* #281: Generated bundle doesn't work on macOS 10.9 and 10.10.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Apple Silicon, anyone?

[Ronald Oussoren via Pythonmac-SIG]

> On 13 Jul 2020, at 22:08, Jack Jansen  wrote:
> 
> Is anyone planning to track the Apple Silicon stuff and/or get a developer 
> system, and see what needs to be done for Python?
> 
> I can help out, if wanted, but I won’t be trying to get a developer system 
> myself because I won’t be able to spend a lot of time

I have a developer system and am working on the port.  My initial focus has 
been on PyObjC on macOS 11 with limited focus on arm64.  That work is mostly 
done, I’ll probably start work on CPython tonight (testing and updating the PRs 
for arm64 support).  

The main two attention points are “Universal 2” binaries and ctypes. I’ve 
already ported pyobjc-core to arm64, that should make validating and updating 
the ctypes patches a lot easier. 

Ronald


—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 6.2.2

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve uploaded PyObjC 6.2.2 to PyPI. The changelog for this release:

#311 : Build for the Metal 
bindings failed on macOS 10.14

#309 : Fix incompatibility 
with macOS 11 in framework loader

Another attempt at giving a nice error message when trying to install on
platforms other than macOS.

The classifiers now correctly identify supported Python versions


As an aside: I’m working on full support for macOS 11, as well as Apple 
Silicon. The development branch for the core bridge already passes its tests on 
Apple Silicon hardware, and updating the framework bindings for macOS is going 
slightly faster than expected.  With some luck there will be a prerelease of 
PyObjC 7 after EuroPython.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 6.2.1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve pushed PyObjC 6.2.1 to PyPI. This is a minor bug fix release:

Issue #299: Ensure package ‘pyobjc’ won’t try to build the PubSub bindings on 
macOS 10.15

Reported by Thomas Buchberger

Minor tweaks to build and pass tests on macOS 10.14 with the latest Xcode that 
can be installed on that version of macOS.

Issue #300: Fix SystemError in block edge case

PyObjC raised a SystemError when converting a callable into an ObjC block when 
the callable is a bound method without positional arguments.

Issue #275: Fix crash on catalina caused by writing to read-only memory.

Patch by Dan Villiom Podlaski Christiansen

PR #302: Make sure the SDK detection works when the version is not in the SDK 
name

Patch by Joshua Root

There were no SDK updates in Xcode 11.5 and Xcode 11.6 (beta)

This is probably the last release in the 6.x train.  My plan is to start 
working on PyObjC 7.0, with support for the next major release of macOS, during 
WWDC.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python 3.8 (latest release)problem

[Ronald Oussoren via Pythonmac-SIG]

> On 29 May 2020, at 12:44, Don Bowers  wrote:
> 
> iMac (2009)  OS X El Capitan v  10.11.6
> 
> Sirs, A few days ago I downloaded and installed the latest release of python 
> 3.8.3.
> 
> All seemed normal at first until I tried to Cut & Paste parts of a script I 
> was working on in the IDLE
> environment. The following are screen shots that are generally self 
> explanatory;
> 
> As can be seen, the cut and copy are greyed out and inoperative and I don’t 
> remember the "set" and "clear" Breakpoints, at the bottom.  It is as if 
> nothing had been selected.
> Such a situation makes the editor practically unusable so I quit out of the 
> IDLE and Python.
> 

I get the same behaviour on macOS 10.15.5, both with 3.8.3 and the 3.9 beta. 
3.7.4 works correctly.   This happens both in the interactive shell and in edit 
windows.  I’d guess this is a problem with the bundled copy of Tk.

Could you file a bug on bugs.python.org ?

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

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Mar 2020, at 22:04, Christopher Barker  wrote:
> 
> On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren  <mailto:ronaldousso...@mac.com>> wrote:
> AFAIK the only difference for this discussion is the “Python.app” trick, and 
> that can be accomplished outside of a framework build as well (but currently 
> is not). 
> 
> Two other differences:
> - A framework build is easier to integrate into applications that are built 
> using Xcode (just drop the framework into list of used frameworks)
> When would that come into play? If you are developing an application that 
> embeds the python interpreter? OR if you are using XCode as your IDE for 
> developing a Python App?

That’s something you can use to embed Python into an ObjC app. 

>  
> - py2app currently doesn’t work properly with a Unix build
> 
> But that could be fixed, yes? (And I think PyInstaller already does work with 
> a unix build)

Sure. Fixing this isn’t too hard, although it will take more time than I’d like 
due to the way the code is structured. 

> 
> I *think* this means that a unix-style build with the python.app "trick" 
> would be appropriate for use in distributions that are otherwise not "mac 
> native" -- e.g. conda, homebrew.
> 
> As to whether a style build would be OK for the python.org 
> <http://python.org/> installer, I'm not so sure. That may still be a 
> candidate for a Framework build --it sure does make installation/uninstalling 
> easier than scatter files all over /usr/local.

Right. That’s an important consideration given that macOS doesn’t have a proper 
native package manager, just an installer.

> 
> Of course, to make any of this happen, someone with the autoconf skills needs 
> to have the time and motivation to do it. I'm not that person (though who 
> knows how far I would have gotten if I'd spent the time I've spent talking 
> about this actually giving it a try :-) )
> 
> So we'll see. Maybe there's no one that both wants this done and has the time 
> and skills to do it -- such is the world of open source.

Agreed. In the end everyone working on Python is a volunteer.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Mar 2020, at 03:11, Christopher Barker  wrote:
> 
> Thanks Jack.
> 
> But I'm still confused about a technical question:
> 
> Does having python itself in a Framework enable anything that having it 
> outside a Framework won't let you do?

AFAIK the only difference for this discussion is the “Python.app” trick, and 
that can be accomplished outside of a framework build as well (but currently is 
not). 

Two other differences:
- A framework build is easier to integratie into applications that are built 
using Xcode (just drop the framework into list of used frameworks)
- py2app currently doesn’t work properly with a Unix build

Ronald

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 13 Mar 2020, at 20:36, Christopher Barker  wrote:
> 
> There is a private API that makes it possible to use GUI libraries outside of 
> an app bundle and that’s used by a number of projects, but I wouldn’t want to 
> use that in Python.
> 
> Is that what TK is doing? 

I don’t know.
> 
> And while probably not good to build it into Python itself, what about 
> building into the GUI toolkits? 
> 
> Do you have a reference to that API?

I don’t have a reference handy, it has come up before either on this list or 
the python tracker (years back). IIRC someone found the API by checking how the 
bundled java VM managed to use GUI APIs without being in an app bundle.

Apple is clearly preferring application code packaged as app bundles, and 
effectively doesn’t care about traditional Unix-y use of macOS. The need for an 
app bundle when using frameworks is just one example of that. Another example 
are the issues that keep popping up when trying to use Apple frameworks in 
child processes after calling os.fork(). 

Because of this I don’t think it is worthwhile to try to work around this 
limitation by calling private APIs. That’s even before considering use cases 
that involve distributing code through the macOS app store.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 11 Mar 2020, at 22:34, Jack Jansen  wrote:

[…]
> 
> - I _think_ that the restriction that a GUI program must be in an App bundle 
> no longer holds, or at least there are ways around it. There are all sorts of 
> programs installed with brew that present a GUI without being in an app 
> bundle. I’m looking at realsense-viewer right now, as an example, and it’s a 
> normal executable in 
> /usr/local/Cellar/librealsense/2.22.0/bin/realsense-viewer with a symlink in 
> /usr/local/bin. 

I’m not sure the limitation is really gone, I still see issues with a number of 
Cocoa APIs when run from a virtualenv environment, which doesn’t use the 
Python.app trick, while the same API works with a venv environement (which does 
use the Python.app trick). One example is 
>. 

There is a private API that makes it possible to use GUI libraries outside of 
an app bundle and that’s used by a number of projects, but I wouldn’t want to 
use that in Python.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/ 


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 12 Mar 2020, at 07:48, Just van Rossum  wrote:
> 
> FWIW, as far as I can tell, a non-framework-build can't be used to build a 
> native macos app, at least not with py2app. 

That’s a limitation in the current version of py2app, but is something that 
could change if needed.

Ronald

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> On 9 Mar 2020, at 17:53, Christopher Barker  wrote:
> 
> All,
> 
> (mostly Ned and Ronald...)
> 
> TL:DR:
> 
> Are there any plans to update the build scripts for the python.org 
>  python(s)? It would be really nice to get the mac builds 
> more inline with the rest of the Unix world.

I’m not very active at the moment, but…  framework builds and in particular the 
embedded Python.app are necessary to be able to use GUI libraries on macOS in 
scripts. The alternative is that users always use py2app/pyinstaller/… to build 
an .app bundle themselves.  

A side-effect of having a Python.framework is that this makes integration with 
Xcode slightly easier, but that’s a secondary concern. We primarily used a 
framework because that was the modern platform way of packaging libraries with 
supporting files (instead of sprinkling everything into /usr/local). 

> 
> Longer version:
> 
> Over on Conda-forge, we've been struggling with the whole Python.app Bundle 
> thing:
> 
> https://github.com/conda-forge/python.app-feedstock/issues/8 
> 
> 
> which resulted in:
> 
> https://github.com/conda-forge/python.app-feedstock/pulls 
> 
> 
> Which looks like it's going to solve the "problem at hand".
> 
> (NOTE: what that PR does is put a symlink in the app bundle to the main 
> executable. So pythonw is a bash script that redirects to the symlink in a 
> bundle which is linked to the regular python executable. I'm amazed that it 
> works, but it seems to)

So you are not using a regular installation… In a regular framework build 
$prefix/bin/python and …/pythonw is a small executable that launches the python 
executable in the embedded Python.app (which is the executable that is 
$prefix/bin/python in unix installs). 
> 
> 
> But really, it seem that it would be better if in the conda world we "did 
> this right", which is to say build a python binary that re-directs to a 
> version inside a bundle to make the OS happy, like is done with the 
> python.org  Framework builds.
> 
> There are a number of issues and discussion out there, semi-summaries here:
> 
> https://github.com/conda-forge/python-feedstock/issues/23 
> 
> 
> But a summary is:
> 
> The Mac requires that a GUI app executable be "inside" nd application bundle 
> to access the GUI. This means that a regular old python interpreter can not 
> be used to run a GUI app (Tk, wxPython, QT, etc.).
> 
> This was "solved" many years ago in the python.org  
> "Framework" builds of Python, by writing a small wrapper around the pythonexe 
> that re-directs itself to one inside an app bundle. This acts just like a 
> regular command line executalbe, and thus "python" and "pythonw" can be links 
> to the same thing.
> 
> However, when Anaconda (and now conda-forge) started, they did not use a 
> Framework build, preferring to keep python more standardized and *nix-y. So 
> they solved the problem by making a "pythonw" command that is a bash script 
> that re-directs itself to a copy of the python executable inside an 
> application bundle. This is delivered as a "python.app" package via conda.
> 
> However: while this hack works fine from the command line, it does not work 
> with setuptools entry points, and other ways of running the app. This has 
> been a thorn in the side of the (admittedly small) group of folks using both 
> conda and developing OS-X Desktop apps. And the setuptools folks seem to have 
> no interest whatsoever in updating setuptools to accommodate pythonw.
> 
> So what I"d like to see happen is for conda-forge to build its python on OS-X 
> with the little wrapper so that it can be used in place of this whole 
> python.app hack. I think there are not technical reasons that can't be done. 
> But the current configure scripts for python.org  don't 
> provide that option, and there has been no one with both an interest in this, 
> the autotools skills, and the time to make it happen.
> 
> I just looked again at the building instructions for the Pyhton.org builds, 
> and they seem to be pretty old. The Mac has moved on and it seems it would b 
> good to updated those build options anyway: Do we need 32 bit anymore? Do we 
> need Universal builds anymore? Should we abandon the Framework build option 
> altogether?
> 
> My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, 
> and the pythonw hack, into an otherwise "standard" unix-like build. 

What’s wrong with using a framework install? That makes is trivial to have side 
by side installs of a number of Python versions, and makes it easy to remove 
one of them (although that’s less of a concern from Conda because the tool 
manages installation and deinstallation for the user).

It should be easy enough to use the pythonw 

[Pythonmac-SIG] ANN: PyObjC moved to GitHub

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve moved the PyObjC repository from BitBucket to GitHub.  The new home is: 
https://github.com/ronaldoussoren/pyobjc/ 


I expect to release a new version of PyObjC soon after the release of macOS 
10.15.4.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: py2app and related projects updated

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve pushed updates for py2app, modulegraph, macholib, altgraph, modulegraph2, 
objectgraph and asl to PyPI.

- py2app now supports Python 3.8 and has some minor bug fixes.
- macholib has some minor bugfixes
- all projects have stricter pyflakes configuration, and were reformatted using 
black.

The major change is that all  projects were moved to GitHub, the repositories 
at BitBucket will no longer be updated.  

Note that PyObjC and closely related projects are still on BitBucket, they will 
move later due to some issues I ran into while migrating the PyObjC repository 
from Mercurial to Git.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

> On 9 Jan 2020, at 00:23, Rand Dvorak  wrote:
> 
> I got it working.  Basically I have a main.py file in Resources that get 
> loaded and run by PyRun_SimpleFile in applicationDidFinishLaunching.  Control 
> is then passed to the python interpreter.  Notice the infinite loop at the 
> bottom which is needed because the interpreter finishes executing the file 
> and exits.  It is needed to keep the python interpreter alive.  I need a 
> better solution to keep the interpreter alive because this eats up too much 
> cpu. It was just a hack to prove that is what was happening.

I’ve quickly scanned 
https://github.com/thecatalinstan/Criollo/wiki/Getting-Started and that seems 
to indicate that the webserver integrates with the regular Cocoa event loop. 
That means you’ll probably need to run the NSRunloop or CFRunloop.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

What is the type of ‘server’?

And I just noticed the metadata block is a bit of, the callable is argument 3 
instead of 2. 

Ronald

--
On the road, hence brief. 

> On 8 Jan 2020, at 17:18, Rand Dvorak  wrote:
> 
> Same result:
> 
>   File "main.py", line 40, in 
> server.get_block_("/", helloHandler)
> TypeError: Argument 3 is a block, but no signature available
> 
> 
>> On Jan 8, 2020, at 03:20, Ronald Oussoren  wrote:
>> 
>> Please change “get_block_” to “get:block:” in the call to 
>> objc.registerMetadataForSelector.
>> 
>> Ronald
>> —
>> 
>> Twitter: @ronaldoussoren
>> Blog: https://blog.ronaldoussoren.net/
>> 
>>> On 8 Jan 2020, at 02:04, Rand Dvorak  wrote:
>>> 
>>> Same results with this code:
>>> 
>>> import objc 
>>> CRApplication = objc.lookUpClass("CRApplication")
>>> objc.registerMetaDataForSelector(
>>> b'CRServer',
>>> b'get_block_',
>>> {
>>> 'arguments': {
>>> 2: {
>>> 'callable': {
>>> 'arguments': {
>>> 0:{'type': b'^v'},
>>> 1:{'type': b'@'},
>>> 2:{'type': b'@'},
>>> 3:{'type': b'?'}
>>> },
>>> '   retval': { 'type': b'v' }
>>> } 
>>> }
>>> }
>>> }
>>> )
>>> 
>>> global server
>>> 
>>> 
>>> def helloHandler(request, response, handler):
>>> response.send_("Hello World!")
>>> handler()
>>> 
>>> if __name__ == "__main__":
>>> server = CRApplication.sharedApplication().delegate().server()
>>> server.get_block_("/", helloHandler)
>>> server.startListening()
>>> 
>>> 
>>>> On Jan 7, 2020, at 04:47, Ronald Oussoren  wrote:
>>>> 
>>>> And given de example on https://criollo.io:
>>>> 
>>>> - The class name is CRServer, not CRApplication
>>>> - The selector is “get:block:” instead of “get_block:”, which also means 
>>>> the block is argument 3 instead of 2.
>>>> 
>>>>>> objc.registerMetaDataForSelector(
>>>>>>  b'CRServer',
>>>>>>  b’get:block:',
>>>>>>  {
>>>>>>  'arguments': {
>>>>>>  3: {
>>>>>>  'callable': {
>>>>>>  'arguments': {
>>>>>>  0:{'type': b'^v'},
>>>>>>  1:{'type': b'@'},
>>>>>>  2:{'type': b'@'},
>>>>>>  3:{'type': b'@'}
>>>>>>  },
>>>>>>  'retval': { 'type': b'v' }
>>>>>>  } 
>>>>>>  }
>>>>>>  }
>>>>>>  }
>>>>>> )
>>>> 
>>>> and later:
>>>> 
>>>>>>  server.get_block_("/", helloHandler)
>>>> 
>>>>> 
>>>> 
>>>> 
>>>> —
>>>> 
>>>> Twitter: @ronaldoussoren
>>>> Blog: https://blog.ronaldoussoren.net/
>>>> 
>>>>> On 7 Jan 2020, at 10:00, Ronald Oussoren via Pythonmac-SIG 
>>>>>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> You also need to remove the call to objc.selector. With correct metadata 
>>>>> “blocks” are callables in Python code.
>>>>> 
>>>>> Ronald
>>>>> —
>>>>> 
>>>>> Twitter: @ronaldoussoren
>>>>> Blog: https://blog.ronaldoussoren.net/
>>>>> 
>>>>>> On 6 Jan 2020, at 23:59, Rand Dvorak  wrote:
>>>>>> 
>>>>>> Same result:
>>>>>> 
>>>>>> Updated code:
>>>>>> 
>>>>>> import objc 
>>>>>> CRApplication = objc.lookUpClass("CRApplication")
>>>>>> objc.registerMetaDataForSelector(
>>>>>>  b'CRApplication',
>>>>>>  b'get_block_',
>>>>>>  {
>>>>>>  'arguments': {
>>>>>>  2: {
>>>>>>

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

Please change “get_block_” to “get:block:” in the call to 
objc.registerMetadataForSelector.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 8 Jan 2020, at 02:04, Rand Dvorak  wrote:
> 
> Same results with this code:
> 
> import objc 
> CRApplication = objc.lookUpClass("CRApplication")
> objc.registerMetaDataForSelector(
>   b'CRServer',
>   b'get_block_',
>   {
>   'arguments': {
>   2: {
>   'callable': {
>   'arguments': {
>   0:{'type': b'^v'},
>   1:{'type': b'@'},
>   2:{'type': b'@'},
>   3:{'type': b'?'}
>   },
>   '   retval': { 'type': b'v' }
>   } 
>   }
>   }
>   }
> )
> 
> global server
> 
>   
> def helloHandler(request, response, handler):
>   response.send_("Hello World!")
>   handler()
>   
> if __name__ == "__main__":
>   server = CRApplication.sharedApplication().delegate().server()
>   server.get_block_("/", helloHandler)
>   server.startListening()
> 
> 
>> On Jan 7, 2020, at 04:47, Ronald Oussoren > <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> And given de example on https://criollo.io: <https://criollo.io/>
>> 
>> - The class name is CRServer, not CRApplication
>> - The selector is “get:block:” instead of “get_block:”, which also means the 
>> block is argument 3 instead of 2.
>> 
>>>> objc.registerMetaDataForSelector(
>>>>b'CRServer',
>>>>b’get:block:',
>>>>{
>>>>'arguments': {
>>>>3: {
>>>>'callable': {
>>>>'arguments': {
>>>>0:{'type': b'^v'},
>>>>1:{'type': b'@'},
>>>>2:{'type': b'@'},
>>>>3:{'type': b'@'}
>>>>    },
>>>>'retval': { 'type': b'v' }
>>>>} 
>>>>}
>>>>}
>>>>}
>>>> )
>> 
>> and later:
>> 
>>>>server.get_block_("/", helloHandler)
>> 
>>> 
>> 
>> 
>> —
>> 
>> Twitter: @ronaldoussoren
>> Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
>> 
>>> On 7 Jan 2020, at 10:00, Ronald Oussoren via Pythonmac-SIG 
>>> mailto:pythonmac-sig@python.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> You also need to remove the call to objc.selector. With correct metadata 
>>> “blocks” are callables in Python code.
>>> 
>>> Ronald
>>> —
>>> 
>>> Twitter: @ronaldoussoren
>>> Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
>>> 
>>>> On 6 Jan 2020, at 23:59, Rand Dvorak >>> <mailto:randdvo...@gmail.com>> wrote:
>>>> 
>>>> Same result:
>>>> 
>>>> Updated code:
>>>> 
>>>> import objc 
>>>> CRApplication = objc.lookUpClass("CRApplication")
>>>> objc.registerMetaDataForSelector(
>>>>b'CRApplication',
>>>>b'get_block_',
>>>>{
>>>>'arguments': {
>>>>2: {
>>>>'callable': {
>>>>'arguments': {
>>>>0:{'type': b'^v'},
>>>>    1:{'type': b'@'},
>>>>2:{'type': b'@'},
>>>>3:{'type': b'@'}
>>>>},
>>>>'   retval': { 'type': b'v' }
>>>>} 
>>>>}
>>>>}
>>>>}
>>>> )
>>>> global server
>>>> 
>>>> def helloHandler(self, request, response, handler):
>>>>response.send_("Hello World!")
>>>>handler()
>>>>
>>>> if __name__ == "__main__":
>>>>server = CRApplication.sharedApplication().delegate().server()
>>>>server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@@'))
>>>>server.startListening()
>>>> 
>>>> 
>>>> r

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

And given de example on https://criollo.io:

- The class name is CRServer, not CRApplication
- The selector is “get:block:” instead of “get_block:”, which also means the 
block is argument 3 instead of 2.

>> objc.registerMetaDataForSelector(
>>  b'CRServer',
>>  b’get:block:',
>>  {
>>  'arguments': {
>>  3: {
>>  'callable': {
>>  'arguments': {
>>  0:{'type': b'^v'},
>>  1:{'type': b'@'},
>>  2:{'type': b'@'},
>>  3:{'type': b'@'}
>>  },
>>  'retval': { 'type': b'v' }
>>  } 
>>  }
>>  }
>>  }
>> )

and later:

>>  server.get_block_("/", helloHandler)

> 


—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 7 Jan 2020, at 10:00, Ronald Oussoren via Pythonmac-SIG 
>  wrote:
> 
> Hi,
> 
> You also need to remove the call to objc.selector. With correct metadata 
> “blocks” are callables in Python code.
> 
> Ronald
> —
> 
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
> 
>> On 6 Jan 2020, at 23:59, Rand Dvorak > <mailto:randdvo...@gmail.com>> wrote:
>> 
>> Same result:
>> 
>> Updated code:
>> 
>> import objc 
>> CRApplication = objc.lookUpClass("CRApplication")
>> objc.registerMetaDataForSelector(
>>  b'CRApplication',
>>  b'get_block_',
>>  {
>>  'arguments': {
>>  2: {
>>  'callable': {
>>  'arguments': {
>>  0:{'type': b'^v'},
>>  1:{'type': b'@'},
>>  2:{'type': b'@'},
>>  3:{'type': b'@'}
>>  },
>>  '   retval': { 'type': b'v' }
>>  } 
>>  }
>>  }
>>  }
>> )
>> global server
>> 
>> def helloHandler(self, request, response, handler):
>>  response.send_("Hello World!")
>>  handler()
>>  
>> if __name__ == "__main__":
>>  server = CRApplication.sharedApplication().delegate().server()
>>  server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@@'))
>>  server.startListening()
>> 
>> 
>> results:
>> 
>> Traceback (most recent call last):
>>   File "main.py", line 37, in 
>> server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@@'))
>> TypeError: Argument 3 is a block, but no signature available
>> 
>> 
>>> On Jan 6, 2020, at 09:27, Ronald Oussoren >> <mailto:ronaldousso...@mac.com>> wrote:
>>> 
>>> 
>>> 
>>>> On 6 Jan 2020, at 00:51, Rand Dvorak >>> <mailto:randdvo...@gmail.com>> wrote:
>>>> 
>>>> 
>>>> I am trying to implement a simple server in PyObjC for the Criollo HTTP 
>>>> server.  The server has a method to set route handlers by passing a block 
>>>> to setup the route and then when it receives and HTTP request for the 
>>>> route it calls the block.  The block has the signature:
>>>> 
>>>> typedef void(^CRRouteBlock)(CRRequest* _Nonnull request, CRResponse* 
>>>> _Nonnull response, CRRouteCompletionBlock _Nonnull completionHandler);
>>>> 
>>>> 
>>>> So, here is my simple proof of concept:
>>>> 
>>>> import objc 
>>>> CRApplication = objc.lookUpClass("CRApplication")
>>>> global server
>>>> 
>>>> def helloHandler(self, request, response, handler):
>>>>response.send_("Hello World!")
>>>>handler()
>>>>
>>>> if __name__ == "__main__":
>>>>server = CRApplication.sharedApplication().delegate().server()
>>>>server.get_block_("/", objc.selector(helloHandler, 
>>>> signature=b'v@:@@@‘))  *** error occurs here
>>>>server.startListening()
>>>> 
>>>> 
>>>> But, when I try to setup the route I get the following error:
>>>> 
>>>> Traceback (most recent call last):
>>>> File "main.py", line 21, in 
>>>>   server.get_block_("/", objc.selector(helloHandler, signa

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

Hi,

You also need to remove the call to objc.selector. With correct metadata 
“blocks” are callables in Python code.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 6 Jan 2020, at 23:59, Rand Dvorak  wrote:
> 
> Same result:
> 
> Updated code:
> 
> import objc 
> CRApplication = objc.lookUpClass("CRApplication")
> objc.registerMetaDataForSelector(
>   b'CRApplication',
>   b'get_block_',
>   {
>   'arguments': {
>   2: {
>   'callable': {
>   'arguments': {
>   0:{'type': b'^v'},
>   1:{'type': b'@'},
>   2:{'type': b'@'},
>   3:{'type': b'@'}
>   },
>   '   retval': { 'type': b'v' }
>   } 
>   }
>   }
>   }
> )
> global server
> 
> def helloHandler(self, request, response, handler):
>   response.send_("Hello World!")
>   handler()
>   
> if __name__ == "__main__":
>   server = CRApplication.sharedApplication().delegate().server()
>   server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@@'))
>   server.startListening()
> 
> 
> results:
> 
> Traceback (most recent call last):
>   File "main.py", line 37, in 
> server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@@'))
> TypeError: Argument 3 is a block, but no signature available
> 
> 
>> On Jan 6, 2020, at 09:27, Ronald Oussoren > <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> 
>> 
>>> On 6 Jan 2020, at 00:51, Rand Dvorak >> <mailto:randdvo...@gmail.com>> wrote:
>>> 
>>> 
>>> I am trying to implement a simple server in PyObjC for the Criollo HTTP 
>>> server.  The server has a method to set route handlers by passing a block 
>>> to setup the route and then when it receives and HTTP request for the route 
>>> it calls the block.  The block has the signature:
>>> 
>>> typedef void(^CRRouteBlock)(CRRequest* _Nonnull request, CRResponse* 
>>> _Nonnull response, CRRouteCompletionBlock _Nonnull completionHandler);
>>> 
>>> 
>>> So, here is my simple proof of concept:
>>> 
>>> import objc 
>>> CRApplication = objc.lookUpClass("CRApplication")
>>> global server
>>> 
>>> def helloHandler(self, request, response, handler):
>>> response.send_("Hello World!")
>>> handler()
>>> 
>>> if __name__ == "__main__":
>>> server = CRApplication.sharedApplication().delegate().server()
>>> server.get_block_("/", objc.selector(helloHandler, 
>>> signature=b'v@:@@@‘))  *** error occurs here
>>> server.startListening()
>>> 
>>> 
>>> But, when I try to setup the route I get the following error:
>>> 
>>> Traceback (most recent call last):
>>> File "main.py", line 21, in 
>>>   server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@'))
>>> TypeError: Argument 3 is a block, but no signature available
>>> 
>>> 
>>> Any ideas how to workaround this issue and implement the route handlers in 
>>> PyObjC?
>> 
>> The code below should do the trick, but eas typed directly into this mail 
>> and might therefore contain syntax errors.
>> 
>> import objc
>> objc.registerMetaDataForSelector(
>>b”CRApplication”,  # name of the class implementing “get_block:”, or 
>> “NSObject”
>>b”get_block:”,
>>   {
>> “arguments”: {
>>   2: {
>> “callable”: {
>>  “arguments”: {
>>   0: { “type”: b”^v” },
>>   1: { “type”: b”@” },
>>   2: { “type”: b”@” },
>>   3: { “type”: b”@” }
>>  },
>>  “retail”: { “type”: b”v” }
>>} 
>>  }
>>   }
>> )
>> 
>> This tells the bridge the signature for the block argument of the 
>> “get_block:” selector, which is information that cannot be retrieved from 
>> the Objective-C runtime.  Argument 2 is the first real argument of ObjC 
>> selectors, after the implicit arguments “self” and “_imp” (which is not 
>> available in python code).
>> 
>> Ronald
>> —
>> 
>> Twitter: @ronaldoussoren
>> Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>
>>> ___
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
>>> <mailto:Pythonmac-SIG@python.org>
>>> https://mail.python.org/mailman/listinfo/pythonmac-sig 
>>> <https://mail.python.org/mailman/listinfo/pythonmac-sig>
>>> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>> 
> 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server

[Ronald Oussoren via Pythonmac-SIG]

> On 6 Jan 2020, at 00:51, Rand Dvorak  wrote:
> 
> 
> I am trying to implement a simple server in PyObjC for the Criollo HTTP 
> server.  The server has a method to set route handlers by passing a block to 
> setup the route and then when it receives and HTTP request for the route it 
> calls the block.  The block has the signature:
> 
> typedef void(^CRRouteBlock)(CRRequest* _Nonnull request, CRResponse* _Nonnull 
> response, CRRouteCompletionBlock _Nonnull completionHandler);
> 
> 
> So, here is my simple proof of concept:
> 
> import objc 
> CRApplication = objc.lookUpClass("CRApplication")
> global server
> 
> def helloHandler(self, request, response, handler):
>   response.send_("Hello World!")
>   handler()
>   
> if __name__ == "__main__":
>   server = CRApplication.sharedApplication().delegate().server()
>   server.get_block_("/", objc.selector(helloHandler, 
> signature=b'v@:@@@‘))  *** error occurs here
>   server.startListening()
> 
> 
> But, when I try to setup the route I get the following error:
> 
> Traceback (most recent call last):
>  File "main.py", line 21, in 
>server.get_block_("/", objc.selector(helloHandler, signature=b'v@:@@'))
> TypeError: Argument 3 is a block, but no signature available
> 
> 
> Any ideas how to workaround this issue and implement the route handlers in 
> PyObjC?

The code below should do the trick, but eas typed directly into this mail and 
might therefore contain syntax errors.

import objc
objc.registerMetaDataForSelector(
b”CRApplication”,  # name of the class implementing “get_block:”, or 
“NSObject”
b”get_block:”,
   {
 “arguments”: {
   2: {
 “callable”: {
  “arguments”: {
   0: { “type”: b”^v” },
   1: { “type”: b”@” },
   2: { “type”: b”@” },
   3: { “type”: b”@” }
  },
  “retail”: { “type”: b”v” }
} 
  }
   }
)

This tells the bridge the signature for the block argument of the “get_block:” 
selector, which is information that cannot be retrieved from the Objective-C 
runtime.  Argument 2 is the first real argument of ObjC selectors, after the 
implicit arguments “self” and “_imp” (which is not available in python code).

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Catalina issue

[Ronald Oussoren via Pythonmac-SIG]

Hi,

This is a change in behaviour in macOS. The workaround is to create an 
NSApplication instance, for example by calling 
Cocoa.NSApplication.sharedApplication().

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 29 Oct 2019, at 19:34, Ben Byram-Wigfield via Pythonmac-SIG 
>  wrote:
> 
> The following two lines work in Mojave, but flag an error in Catalina:
> 
 from AppKit import NSSavePanel
 panel = NSSavePanel.savePanel()
> 
> The error is:
> 
> 2019-10-29 18:24:22.275 Python[6577:255233] *** Assertion failure in 
> +[NSServiceViewController currentAppIsViewService], 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-462/NSViewService.m:140
> 2019-10-29 18:24:22.275 Python[6577:255233] *** Assertion failure in 
> +[NSServiceViewController currentAppIsViewService], 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-462/NSViewService.m:140
> 2019-10-29 18:24:22.342 Python[6577:255347] +[NSXPCSharedListener 
> endpointForReply:withListenerName:]: an error occurred while attempting to 
> obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
> 
> This is with PyObjC 5.2. I get the same error (or not) in python 2.7 and 
> python 3.7.
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Catalina issue

[Ronald Oussoren via Pythonmac-SIG]

Hi,

Thanks for the report. I can reproduce this in a VM running 10.15.1 (using a 
virtualenv environment).  I’ve filed issue #282 about this, to help me remember 
to investigate this.

/usr/bin/python on the same system works fine, but is using an ancient version 
of PyObjC.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 29 Oct 2019, at 19:34, Ben Byram-Wigfield via Pythonmac-SIG 
>  wrote:
> 
> The following two lines work in Mojave, but flag an error in Catalina:
> 
 from AppKit import NSSavePanel
 panel = NSSavePanel.savePanel()
> 
> The error is:
> 
> 2019-10-29 18:24:22.275 Python[6577:255233] *** Assertion failure in 
> +[NSServiceViewController currentAppIsViewService], 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-462/NSViewService.m:140
> 2019-10-29 18:24:22.275 Python[6577:255233] *** Assertion failure in 
> +[NSServiceViewController currentAppIsViewService], 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-462/NSViewService.m:140
> 2019-10-29 18:24:22.342 Python[6577:255347] +[NSXPCSharedListener 
> endpointForReply:withListenerName:]: an error occurred while attempting to 
> obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
> 
> This is with PyObjC 5.2. I get the same error (or not) in python 2.7 and 
> python 3.7.
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 6.0.1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve uploaded PyObjC 6.0.1 to PyPI. This fixes the annoying lines of debug 
output in the 6.0 release.

Ronald

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 6.0

[Ronald Oussoren via Pythonmac-SIG]

I've uploaded PyObjC 6.0 to PyPI. This is a major feature release, the two most 
important changes are the addition of support for frameworks and APIs 
introduced in macOS 10.15 (Catalina), and the removal of support for Python 2.7.

PyPI has wheels for 64-bit builds of Python 3.6, 3.7 and 3.8. The source should 
still work with 32-bit builds  of Python, but those are no longer tested.

At the time of writing the source code is still in the branch 
"pyobjc-6-branch". 

The full list of changes:

* Removed Python 2 support from the C extension in pyobjc-core

* Reformatted code in pyobjc-core:

  - Use "black" for Python code
  - Use "clang-format" for Objective-C code

As a side-effect of this all usage of "NS_DURING" and "PyObjC_DURING"
has been replaced by the expansion of those macros, mostly because
"clang-format" doesn't understand these kinds of blocks.

Replacing PyObjC_DURING  by its expansion also reduces the knowledge
needed to understand what's going on w.r.t. the Python GIL.

The macro PyObjC_DURING, and its siblings, have been removed as well.

* Updated bindings for macOS 10.15 (Xcode 11.0)

* The userspace driver frameworks introduced in macOS 10.15
  (DriverKit and related frameworks) will not be exposed through
  PyObjC. Please let me know if you have a good
  use case for using these frameworks with Python.

* Add new framework wrappers for all other new frameworks
  in macOS 10.15:

  - AuthenticationServices
  - CoreHaptics
  - CoreMotion
  - DeviceCheck
  - ExecutionPolicy
  - FileProvider
  - FileProviderUI
  - LinkPresentation
  - OSLog
  - PencilKit
  - PushKit
  - QuickLookThumbnailing
  - Speech
  - SoundAnalysis
  - SystemExtensions

* Add new framework wrappers for a number of older
  frameworks:

  - MetalKit (new in macOS 10.11)

* Issue #271: Fix crash when creating NSData objects on macOS 10.15

P.S. This release is later than I'd like for various reasons, but mostly 
because I've spent less time at my computer the last couple of weeks.

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: PyObjC 5.3

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve uploaded PyObjC 5.3 to PyPI.  This is a minor bug fix release and also 
ships with wheels for Python 3.8.

Changes:

* PR 21: Switch xcodebuild invocation to xcrun for sdk path

  Patch by Clément Bouvier

* #271: Fix crash when creating NSData objects on macOS 10.15

* Fix compile error on macOS 10.15


Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Looking for PyObjC and py2app users

[Ronald Oussoren via Pythonmac-SIG]

Hi,

Thanks for all responses, both here and on Twitter.  I haven’t had a chance to 
seriously look at everything as I’m on my post-EuroPython holiday, but will do 
so when I get back home. 

Ronald
--
On the road, hence brief. 

Op 14 jul. 2019 om 16:52 heeft Ronald Oussoren  het 
volgende geschreven:

> Hi,
> 
> I’m looking for users and usages of PyObjC and py2app for a number of 
> reasons. 
> 
> - I’m personally interested in what people are doing with my projects, this 
> not just strokes my ego but also tends to show fun usecases
> - I’d like to add information to the documentation on how and why PyObjC is 
> used
> - I’d like to add links to (OSS) projects to the documentation, amongst 
> others as more realistic examples than the example code in the repository
> - Links to source code can help me improve PyObjC
> 
> For py2app I have similar reasons for being interested, but there’s another 
> one: py2app is getting long in the tooth and requires tweaking for a lot of 
> programs using it.  Finding examples of such tweaks helps me improve py2app, 
> and can also help in creating an integration testsuite for py2app.
> 
> Feel free to contact me directly.
> 
> Ronald
> —
> 
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
> 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Looking for PyObjC and py2app users

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’m looking for users and usages of PyObjC and py2app for a number of reasons. 

- I’m personally interested in what people are doing with my projects, this not 
just strokes my ego but also tends to show fun usecases
- I’d like to add information to the documentation on how and why PyObjC is used
- I’d like to add links to (OSS) projects to the documentation, amongst others 
as more realistic examples than the example code in the repository
- Links to source code can help me improve PyObjC

For py2app I have similar reasons for being interested, but there’s another 
one: py2app is getting long in the tooth and requires tweaking for a lot of 
programs using it.  Finding examples of such tweaks helps me improve py2app, 
and can also help in creating an integration testsuite for py2app.

Feel free to contact me directly.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] modulegraph2 2.0a1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’m happy to announce a new library: modulegraph2 version 2.0a1.  Modulegraph2 
is a complete rewrite of the modulegraph library that powers py2app and will 
end up in py2app in the future.

The new library is python 3 only and has proper test coverage. This should make 
it a lot easier to evolve the library in the future.

A longer write-up is at my blog: 
https://blog.ronaldoussoren.net/2019/02/03/modulegraph-a-python.html 


Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PMPrinterPrintWithProvider

[Ronald Oussoren via Pythonmac-SIG]

> On 25 Jan 2019, at 15:47, Kevin Walzer  wrote:
> 
> On 1/25/19 5:44 AM, Ronald Oussoren via Pythonmac-SIG wrote:
>> These APIs are not available through PyObjC at this time. Why do you want 
>> these APIs instead of the higher level APIs in AppKit?
> 
> Since these are C API's, it should be possible to access them through ctypes, 
> yes?

Probably.  It’s probably easier to “just” create a minimal wrapper using PyObjC 
that exposes just the bits that you want to use. Which reminds me that I should 
write a blog about creating custom API bindings one of these days...

Ronald
--

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 5.1.2

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve pushed PyObjC 5.1.2 to PyPI. This release contains a number of bugfixes:

* #254: Fix compile error on macOS 10.9 or earlier

* #255: Calling completion handler failed due to incomplete runtime info

  PyObjC's metadata system didn't automaticly set the call signature
  for blocks passed into a method implemented in Python. This causes problems
  when the ObjC or Swift block does not have signature information in the
  ObjC/blocks runtime.

* Use MAP_JIT when allocating memory for the executable stubs for Python
  methods.

  With the "restricted" runtime you'll have to add the 
"com.apple.security.cs.allow-jit"
  entitlement to use this flag, in earlier versions you'd have to use
  a different entitlement: 
"com.apple.security.cs.allow-unsigned-executable-memory".

  The MAP_JIT flag is only used on macOS 10.14 or later.

* Ensure that PyObjC can be built using /usr/bin/python on macOS 10.14

  This failed due the problems with header files in the SDK included with Xcode 
10.

Regards,

  Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 5.1.1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve pushed PyObjC 5.1.1 to PyPI. This is a very minor feature update: it adds 
a small number of symbols introduced in the macOS 10.14.1 SDK included with 
Xcode 10.1.

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

Re: [Pythonmac-SIG] [Pyobjc-dev] notarization works! (was Re: not that)

[Ronald Oussoren via Pythonmac-SIG]

> On 29 Oct 2018, at 18:22, Glyph  wrote:
>>> 
>> 
>> Which package needs _cffi_backend? I can add a recipe for that to py2app to 
>> do this automagically.
> 
> This may sound obvious, but: cffi :-).  In my case, pyOpenSSL -> cryptography 
> -> cffi.

I’ll look into adding a recipe for this to py2app.  

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

Re: [Pythonmac-SIG] [Pyobjc-dev] notarization works! (was Re: not that)

[Ronald Oussoren via Pythonmac-SIG]

> On 29 Oct 2018, at 07:58, Ronald Oussoren via Pyobjc-dev 
>  wrote:
> 
> MAP_JIT is a mmap flag that’s apparently introduced in 10.14. The slides at 
> https://developer.apple.com/videos/play/wwdc2018/702/ 
> <https://developer.apple.com/videos/play/wwdc2018/702/> mention this flag and 
> the hardened runtime.  
> 
> I guess we should add this flag to the code in 
> Modules/_ctypes/malloc_closure.c CPython) and in the similar code in PyObjC.  
> The annoying bit is that the flag is new in 10.14, and CPython installers are 
> created on 10.9 which means those won’t include the new flag for a long time. 
> 
> I’ll have to check if using MAP_JIT is ok when deploying on older macOS 
> versions, or if the code should do a runtime version check. 

I filed an issue with PyObjC to ensure I don’t forget to look into this: 
https://bitbucket.org/ronaldoussoren/pyobjc/issues/253/use-map_fixed-on-macos-1014
 
<https://bitbucket.org/ronaldoussoren/pyobjc/issues/253/use-map_fixed-on-macos-1014>.

I’ll look into ctypes when I have a good solution for PyObjC.

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

Re: [Pythonmac-SIG] [Pyobjc-dev] notarization works! (was Re: not that)

[Ronald Oussoren via Pythonmac-SIG]

> On 29 Oct 2018, at 00:56, Glyph  wrote:
> 
> 
> 
>> On Oct 28, 2018, at 2:57 PM, Glyph > > wrote:
>> 
>>> I wonder what the “hardened runtime” option actually does and enforces.   
>>> In 3.7 the line in ctypes/__init__.py that causes the exception is a call 
>>> that creates a dummy C function, and likely triggers the first allocation 
>>> for storing a libffi closure which could be something the hardened runtime 
>>> doesn’t like (being writeable + executable memory). 
>> 
>> Interesting. Perhaps what I want is simply 
>> https://developer.apple.com/documentation/security/com_apple_security_cs_allow-unsigned-executable-memory
>>  
>> 
>>  then?  Any chance you know how to jam that into a `codesign` command line 
>> somehow? :-)
>> 
> 
> Thank you so much for this tip, Ronald!  This was much easier than I 
> anticipated, and things are working now!

Great.

> 
> The relevant entitlements file is literally just:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> 
> 
>   com.apple.security.cs.allow-unsigned-executable-memory
>   
> 
> 
> 
> I dropped that in a file, added `--entitlements=$THAT_FILE.plist` to my 
> codesign invocations, removed all my workarounds for ctypes et. al. (except 
> for the hard-coded 'import _cffi_backend' still necessary to convince 
> modulegraph to include enough code for SSL to work), and then tried launching 
> my app.  

Which package needs _cffi_backend? I can add a recipe for that to py2app to do 
this automagically.


> Success!  Then I tried notarizing it: also success!  Time permitting, I'll be 
> updating my blog post at 
> https://glyph.twistedmatrix.com/2018/01/shipping-pygame-mac-app.html 
>  with 
> this information, and possibly publishing the now unfortunately somewhat 
> complex tooling I use to do signing now.
> 
> So I don't know if I'm the first to do this, but looking at the archives for 
> these lists I seem to be the first to report it: you can successfully 
> codesign and notarize apps created with py2app and python 3.6!
> 
> It seems to me that whatever "MAP_JIT" is (an mmap flag, I'm guessing?) 
> libffi needs to be using it for the memory it places synthetic closures into, 
> so that this entitlement won't be necessary with some future version of 
> Python.  But it looks like Apple is not pushing particularly hard to 
> deprecate this one right now, thank goodness :-).

MAP_JIT is a mmap flag that’s apparently introduced in 10.14. The slides at 
https://developer.apple.com/videos/play/wwdc2018/702/ 
 mention this flag and 
the hardened runtime.  

I guess we should add this flag to the code in Modules/_ctypes/malloc_closure.c 
CPython) and in the similar code in PyObjC.  The annoying bit is that the flag 
is new in 10.14, and CPython installers are created on 10.9 which means those 
won’t include the new flag for a long time. 

I’ll have to check if using MAP_JIT is ok when deploying on older macOS 
versions, or if the code should do a runtime version check. 

Ronald


> 
> -glyph
> ___
> Pyobjc-dev mailing list
> pyobjc-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app apps codesigned with "--options runtime", i.e. any notorizable app, fails to launch with ctypes error (was Re: [Pyobjc-dev] ctypes MemoryError when attempting to launch nota

[Ronald Oussoren via Pythonmac-SIG]

> On 28 Oct 2018, at 19:20, Glyph  wrote:
> 
> 
> 
>>> 
>>> Curiously, this is the same traceback that comes from 
>>> https://forum.kodi.tv/showthread.php?tid=329171 
>>> , which suggests it's 
>>> something fundamental to strict shared-library sandboxing that ctypes trips 
>>> over when trying to initialize itself.
>>> 
>>> Does anyone have experience with this, or ideas about what to do?
>> 
>> I’m afraid not. I currently get away with not signing apps at all, although 
>> properly supporting signing is on my way too long wish list for py2app.  
> 
> The ability to distribute unsigned apps is not-so-slowly going away; even the 
> ability to distribute non-notarized apps has a very limited shelf-life at 
> this point.  So this ought to be an alarming development for everyone - 
> having Python apps effectively banned from macOS distribution is a big 
> potential problem :-\.

Yup. That’s something that worries me as well, and not just for Python apps.  
Not being able to run your own code without paying Apple for the privilege is 
not something I look forward to.  I’m still hoping that the option to run 
unsigned code doesn’t go away.


> 
> The good news here is that aside from having to write a little for loop in 
> shell (shown below) getting the app codesigned previously was easy, and my 
> app *did* pass notarization, so nothing that py2app is doing is breaking 
> things on apple's end.  It's just a matter of a ctypes bug.
> 
> As I see it, there's 2 problems here:
> 
> py2app's __boot__.py should fail more gracefully if initializing ctypes 
> doesn't work, since not everybody needs ctypes.  Shall I file this on the 
> tracker?

Yes please.  I’d prefer a solution that doesn’t involve ignoring errors, but 
that’s probably the easiest fix for now.  What’s the exception you’re getting? 
Tweaking the code in py2app/bootstrap/ctypes_setup.py to ignore that exception 
would be trivial. 


> ctypes itself should address whatever eldritch hideousness is causing this; 
> in addition to the windows security layer stuff I found, grsecurity TPE 
> causes the same traceback: https://bugs.python.org/issue28429 
> 
>> With some luck there’s some entitlement or code signing option that causes 
>> this problem.  What is the output of "codesign --display --verbose=4” for 
>> the application? Both with and without notarisation? 
> 
> Sorry, my original message was not clear.  App notarization itself is not the 
> problem, it's the "stricter requirements" that I ambiguously referenced.  The 
> requirement in question is the '--options runtime' flag passed to 'codesign'. 
>  So you can just codesign an app (even with an ad-hoc identity, you 
> technically could do this without even having a valid cert, although the way 
> one generates one of those escapes me) with the 'runtime' option, you can 
> reproduce this.
> 
> So if I sign my app like this:
> 
> #!/bin/bash
> find "${NAME}.app" -iname '*.so' -or -iname '*.dylib' |
> while read libfile; do
>   codesign --sign "${IDENTITY}" \
>--deep "${libfile}" \
>--force \
>--options runtime;
> done;
> 
> codesign --sign "${IDENTITY}" \
>  --deep "${NAME}.app" \
>  --force \
>  --options runtime;
> 
> and then run it as "./${NAME}.app/Contents/MacOS/${NAME}".  I immediately get 
> the traceback given above.

Great. That should make it easier for me to reproduce the issue. 

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

Re: [Pythonmac-SIG] py2app apps codesigned with "--options runtime", i.e. any notorizable app, fails to launch with ctypes error (was Re: [Pyobjc-dev] ctypes MemoryError when attempting to launch nota

[Ronald Oussoren via Pythonmac-SIG]

> On 28 Oct 2018, at 19:47, Glyph  wrote:
> 
> 
> 
>> On Oct 28, 2018, at 11:20 AM, Glyph > <mailto:gl...@twistedmatrix.com>> wrote:
>> 
>> 
>> 
>>> On Oct 28, 2018, at 2:27 AM, Ronald Oussoren >> <mailto:ronaldousso...@mac.com>> wrote:
>> 
>>>> 
>>>> Curiously, this is the same traceback that comes from 
>>>> https://forum.kodi.tv/showthread.php?tid=329171 
>>>> <https://forum.kodi.tv/showthread.php?tid=329171>, which suggests it's 
>>>> something fundamental to strict shared-library sandboxing that ctypes 
>>>> trips over when trying to initialize itself.
>>>> 
>>>> Does anyone have experience with this, or ideas about what to do?
>>> 
>>> I’m afraid not. I currently get away with not signing apps at all, although 
>>> properly supporting signing is on my way too long wish list for py2app.  
>> 
>> The ability to distribute unsigned apps is not-so-slowly going away; even 
>> the ability to distribute non-notarized apps has a very limited shelf-life 
>> at this point.  So this ought to be an alarming development for everyone - 
>> having Python apps effectively banned from macOS distribution is a big 
>> potential problem :-\.
>> 
>> The good news here is that aside from having to write a little for loop in 
>> shell (shown below) getting the app codesigned previously was easy, and my 
>> app *did* pass notarization, so nothing that py2app is doing is breaking 
>> things on apple's end.  It's just a matter of a ctypes bug.
> 
> On that note: more good news.  While I haven't round-tripped through 
> notarization again yet, this is a bit less dire than it first appeared.  If I 
> prevent the import of ctypes with an `import sys; sys.modules['ctypes'] = 
> None`, and add a 'sed' script to my build process to prevent _setup_ctypes 
> from running in __boot__, then the app launches again.
> 
> Apparently my app doesn't actually need ctypes.

Good to hear that. 

> 
> The problem seems to be that Twisted includes a ctypes import; modulegraph 
> sees this and thinks there is a hard dependency, and inserts the ctypes setup 
> blob into __boot__.  However, this is a conditional import, and it's for 
> Windows support anyway.

Hmm…. I wonder what’s the best way forward here. I could add on option to 
disable ctypes support, but that is a kludge.  A weak importing hook (something 
like the never withdrawn PEP 369) could execute this code only when actually 
needed, but I have no idea how hard it would be to implement this.


> 
> (There also seem to be problems with cffi-using libraries, but not other 
> shared objects, so maybe this is a bug in libffi; however, these don't 
> interfere with py2app itself starting up.)

Interesting…  I haven’t had complaints about PyObjC yet, and that also uses 
libffi.  

I wonder what the “hardened runtime” option actually does and enforces.   In 
3.7 the line in ctypes/__init__.py that causes the exception is a call that 
creates a dummy C function, and likely triggers the first allocation for 
storing a libffi closure which could be something the hardened runtime doesn’t 
like (being writeable + executable memory). 

P.S. I just noticed that the traceback in your initial message doesn’t include 
the actual exception, just the traceback. 


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

Re: [Pythonmac-SIG] [Pyobjc-dev] ctypes MemoryError when attempting to launch notarized app

[Ronald Oussoren via Pythonmac-SIG]

> On 28 Oct 2018, at 06:27, Glyph  wrote:
> 
> I adjusted my code-signing to use the new, stricter requirements imposed by 
> app notarization.  I managed to get it successfully notarized, but the app is 
> now non-functional as a result: at startup, I get:
> 
> Traceback (most recent call last):
>   File "my.app/Contents/Resources/__boot__.py", line 93, in 
> _setup_ctypes()
>   File "my.app/Contents/Resources/__boot__.py", line 86, in _setup_ctypes
> from ctypes.macholib import dyld
>   File "", line 971, in _find_and_load
>   File "", line 955, in _find_and_load_unlocked
>   File "", line 656, in _load_unlocked
>   File "", line 626, in _load_backward_compatible
>   File "ctypes/__init__.pyc", line 538, in 
>   File "ctypes/__init__.pyc", line 273, in _reset_cache
> 
> (If anyone wants to follow along in the traceback, this is using python.org 
> 3.6.6.)

On what version of macOS? I expect 10.14 because that’s the only release that 
actually knows about notarization, but enabling this feature might also affect 
how the app is signed.
> 
> This happens before any of my code even runs, so I can't just try to avoid 
> ctypes.

You could patch the __boot__.py file before signing to see if that helps. 
Although this should cause problems further on, the call to _setup_ctypes 
should only be created when some code in your app bundle has a dependency on 
ctypes. 

> 
> Curiously, this is the same traceback that comes from 
> https://forum.kodi.tv/showthread.php?tid=329171, which suggests it's 
> something fundamental to strict shared-library sandboxing that ctypes trips 
> over when trying to initialize itself.
> 
> Does anyone have experience with this, or ideas about what to do?

I’m afraid not. I currently get away with not signing apps at all, although 
properly supporting signing is on my way too long wish list for py2app.  


With some luck there’s some entitlement or code signing option that causes this 
problem.  What is the output of "codesign --display --verbose=4” for the 
application? Both with and without notarisation? 

Ronald

> 
> -glyph
> ___
> Pyobjc-dev mailing list
> pyobjc-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 5.1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve pushed PyObjC 5.1 to PyPI. This is a minor feature release.  The most 
interesting change is that the Objective-C proxies for builtin Python types now 
support NSSecureCoding.


The full list of changes:

Xcode 10 “GM” contains one difference from the last beta: the constant 
MLComputeUnitsCPUAndGPU in the CoreML bindings.

#222: Add a proxy for C’s “FILE*” type on Python 3. This is not necessary on 
Python 2 because the default IO stack on Python 2 already uses FILE* internally.

This proxy type is very minimal and shouldn’t not be used for general I/O.

Bindings are up-to-date w.r.t. Xcode 10.1 (beta)

Updated the support code for framework wrappers to be able to emit deprecation 
warnings on the first import of a deprecated constants (functions and methods 
will only raise a deprecation warning when called).

This is just an infrastructure change, the actual framework bindings do not yet 
contain the information used to emit deprecation warnings.

Add metadata for deprecation warnings to the “Contacts” framework

#252: Import ABCs from collections.abc instead of collections because the 
latter is deprecated.

#180, #251: Instances of most builtin value types and sequences (int, float, 
str, unicode, tuple, list, set, frozenset and dict) can now be written to 
archives that require secureCoding.

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

[Pythonmac-SIG] [ANN] py2app 0.18

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve released py2app 0.18 on PyPI. The only change w.r.t. 0.17 is a recipe for 
“six.moves”, that should also work when the “six” library has been vendored by 
some other package.

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

Re: [Pythonmac-SIG] py2app -A and virtual environments

[Ronald Oussoren via Pythonmac-SIG]

> On 28 Sep 2018, at 10:34, Just van Rossum  wrote:
> 
> Following up to this: it seems line 1832 in py2app/build_app.py isn’t correct 
> anymore, with Python 3 venv behavior:
> 
>if os.path.exists(os.path.join(sys.prefix, ".Python")):
> 
> Not sure how to fix it. If I force this code path to be taken, I get an 
> AttributeError on sys.real_prefix, so I guess a bit more needs to be done.

The line of code is for virtualenv support. I’ll have to check the code to see 
what’s needed to support venv here as well.

Ronald

> 
> Just
> 
>> On 27 Sep 2018, at 16:05, Just van Rossum  wrote:
>> 
>> Hi all,
>> 
>> py2app seems to do the right thing from an activated virtual env when 
>> building a full app. However, for speedy development I use the py2app -A 
>> option a lot, and when running such an alias bundle it appears to use the 
>> global Python install instead of the virtual env. Is there a way around that?
>> 
>> Just
>> 
> 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [ANN] PyObjC 5.0

[Ronald Oussoren via Pythonmac-SIG]

> On 21 Sep 2018, at 23:24, Glyph  wrote:
> 
> 
> 
>> On Sep 21, 2018, at 4:50 AM, Ronald Oussoren > <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> 
>> 
>>> On 21 Sep 2018, at 05:59, Glyph >> <mailto:gl...@twistedmatrix.com>> wrote:
>>> 
>>> On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG 
>>> mailto:pythonmac-sig@python.org>> wrote:
>>>> 
>>>> PyObjC 5.0 is out
>>> 
>>> Thanks again for your tireless (or at least apparently tireless) 
>>> maintenance, Ronald!
>>> 
>>>> * Added bindings for the “CarbonCore” subframework of the “CoreServices” 
>>>> framework.
>>>> 
>>>> Most APIs in this subframework are not available to Python, only those 
>>>> APIs that are not deprecated and seem interesting are exposed.
>>> 
>>> One thing I wondered about when I saw "carbon" here is that I wonder if the 
>>> APIs that could make 
>>> https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html
>>>  
>>> <https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html>
>>>  are exposed again?  
>> 
>> The API used in that example is not exposed through PyObjC at this time 
>> (AFAIK it is part of “Carbon.framework”, not the CarbonCore sub framework of 
>> “CoreServices.framework”. 
>> 
>> I’m open to adding bindings to interesting APIs, but note that 
>> “RegisterEventHotKey” is not documented on Apple’s website and might not be 
>> the right solution for modern code. I don’t know yet what the right solution 
>> is though (a number of APIs that are exposed through PyObjC can be used to 
>> implement similar functionality).
> 
> If there were a more modern solution I'd gladly use it rather than asking you 
> to expose gross and ancient Carbon APIs :).  Which APIs that are already 
> exposed can do this?

Good question :-).  I thought CGEventTapCreate and related APIs could be used 
for this, but now that I’ve reread the documentation I no longer think so. 
MASShortCut still uses the Carbon APIs in its implementation, which seems to 
confirm that there is no good modern alternative for the RegisterEventHotKey 
API.

> 
>>> The cautions that the relevant Carbon APIs require 32-bit mode are 
>>> inaccurate; 
>>> https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html 
>>> <https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html>
>>>  explains that they're still supported in sandboxed Mac App Store apps, so 
>>> they're just poorly documented, not deprecated.  (It seems that there's 
>>> never been a proper Cocoa replacement for this functionality, just a couple 
>>> of popular wrappers floating around out there…)
>>> 
>>> This is something I have wanted to do in Python many times, but never quite 
>>> badly enough to figure out all the build gymnastics required to get the 
>>> bindings for https://github.com/shpakovski/MASShortcut 
>>> <https://github.com/shpakovski/MASShortcut> built and bundled with my 
>>> application.
>> 
>> I’ll look into exposing this API for PyObjC 5.1, even if that means adding a 
>> very limited set of bindings for Carbon.framework.
> 
> Thanks!
> 
>>> -glyph
>>> 
>>> P.S.: speaking of build gymnastics, does anyone on this list happen to have 
>>> a way to use CocoaPods or something similar to pull in open source Cocoa 
>>> frameworks to a PyObjC application?
>> 
>> I haven’t looked into this yet.  I guess the hardest part is creating the 
>> metadata for constants and pointer arguments. Could you file and issue for 
>> this? 
> 
> Sure, sometime this weekend I'll try to write it up.

I have created an experimental binding to MASShortcut on my bitbucket account: 
https://bitbucket.org/ronaldoussoren/pyobjc-masshortcut 
<https://bitbucket.org/ronaldoussoren/pyobjc-masshortcut>. This library can be 
installed using “pip install pyobjc-MASShortcut==1.0a0” (and has a wheel if you 
use a 64-bit installation of Python 3.7)

This “works” in the sense that I ran my unit tests with Python 3.6 (64-bit), 
but I have done no testing beyond that.

Creating the bindings was fairly easy, but harder than it should be because the 
tooling I use to create bindings is primarily created for Apple’s system 
frameworks and has some issues with 3th-party frameworks. I do want to improve 
the tooling for this, but don’t know when I’ll get around to actually doing 
this.

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

Re: [Pythonmac-SIG] [ANN] PyObjC 5.0

[Ronald Oussoren via Pythonmac-SIG]

> On 21 Sep 2018, at 05:59, Glyph  wrote:
> 
> On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG 
> mailto:pythonmac-sig@python.org>> wrote:
>> 
>> PyObjC 5.0 is out
> 
> Thanks again for your tireless (or at least apparently tireless) maintenance, 
> Ronald!
> 
>> * Added bindings for the “CarbonCore” subframework of the “CoreServices” 
>> framework.
>> 
>> Most APIs in this subframework are not available to Python, only those APIs 
>> that are not deprecated and seem interesting are exposed.
> 
> One thing I wondered about when I saw "carbon" here is that I wonder if the 
> APIs that could make 
> https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html 
> <https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html>
>  are exposed again?  

The API used in that example is not exposed through PyObjC at this time (AFAIK 
it is part of “Carbon.framework”, not the CarbonCore sub framework of 
“CoreServices.framework”. 

I’m open to adding bindings to interesting APIs, but note that 
“RegisterEventHotKey” is not documented on Apple’s website and might not be the 
right solution for modern code. I don’t know yet what the right solution is 
though (a number of APIs that are exposed through PyObjC can be used to 
implement similar functionality).

> The cautions that the relevant Carbon APIs require 32-bit mode are 
> inaccurate; 
> https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html 
> <https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html> 
> explains that they're still supported in sandboxed Mac App Store apps, so 
> they're just poorly documented, not deprecated.  (It seems that there's never 
> been a proper Cocoa replacement for this functionality, just a couple of 
> popular wrappers floating around out there…)
> 
> This is something I have wanted to do in Python many times, but never quite 
> badly enough to figure out all the build gymnastics required to get the 
> bindings for https://github.com/shpakovski/MASShortcut 
> <https://github.com/shpakovski/MASShortcut> built and bundled with my 
> application.

I’ll look into exposing this API for PyObjC 5.1, even if that means adding a 
very limited set of bindings for Carbon.framework.

> 
> -glyph
> 
> P.S.: speaking of build gymnastics, does anyone on this list happen to have a 
> way to use CocoaPods or something similar to pull in open source Cocoa 
> frameworks to a PyObjC application?

I haven’t looked into this yet.  I guess the hardest part is creating the 
metadata for constants and pointer arguments. Could you file and issue for 
this?  

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

[Pythonmac-SIG] [ANN] PyObjC 5.0

[Ronald Oussoren via Pythonmac-SIG]

PyObjC 5.0 is out

The release of macOS 10.14 is near, it is therefore time to release a new major 
version of PyObjC. I’ve uploaded PyObjC to PyPI, it can be installed using 
“python3 -m pip install -U pyobjc”.

What is PyObjC

The PyObjC project provides bindings to most of Apple’s higher-level APIs 
(frameworks). More information about these bindings and how to use PyObjC can 
be found on the PyObjC website.

What is new

The main feature of this release is the addition of support for APIs introduced 
in macOS 10.14 (Mojave).

In particular:
* Adds support for macOS 10.14 (Mojave)
* This release updates the framework wrappers with support for new APIs in 
macOS 10.14 and adds bindings for the following new frameworks:

•  AdSupport
•  CoreAudio (new in macOS 10.0)
•  CoreAudioKit (new in macOS 10.4)
•  CoreMedia (new in macOS 10.7)
•  CoreMediaIO (new in macOS 10.7)
•  DiscRecording (new in macOS 10.2)
•  DiscRecordingUI (new in macOS 10.2)
•  DVDPlayback (new in macOS 10.3)
•  MediaToolbox
•  NaturalLanguage
•  Network
•  OSAKit (new in macOS 10.4)
•  UserNotifications
•  VideoSubscriberAccount
•  VideoToolbox (new in macOS 10.8)


* Added two features that can help with gating code on the version of macos:

1) The constants “objc.MAC_OS_X_VERSION_CURRENT” can be compared with one of 
the “objc.MAC_OS_X_VERSION_…” contants.

2) The function “objc.macos_avaiable(major, minor[, patch])” returns true if 
the current macOS version is at least the specified version, comparable with 
“@available” in Swift.

* PR19: Fix deprecation warning in bridgesupport support module
Patch by: Mickaël Schoentgen

* Creating objc.ObjCPointer instances now results in a Python warning, instead 
of an unconditional message on stdout.

* System bridgesupport XML files (normally not used by PyObjC) can contain 
constant numbers with value “inf”, PyObjC now knows how to handle those.

* Added bindings for the “Metadata” subframework of the “CoreServices” 
framework.

* Added bindings for the “CarbonCore” subframework of the “CoreServices” 
framework.

Most APIs in this subframework are not available to Python, only those APIs 
that are not deprecated and seem interesting are exposed.

* The separate framework wrappers DictionaryServices, LaunchServices and 
SearchKit are deprecated, use the CoreServices bindings instead.

These framework wrappers still exists, but are effectively aliases for 
CoreServices with this release. Because of this these bindings can expose more 
symbols than previously.

* Fix unexpected exception when trying to call getattr on a framework wrapped 
with a name that isn’t a valid identifier.

* Issue 244: Bad metadata for CGPDFOperatorTableSetCallback

* Issue 247: Fix crash in regression test case

* One specific test in pyobjc-core crashed the interpreter when run separately. 
Because of this I’ve disabled an optimization that uses alloca instead of 
PyMem_Malloc to allocate memory for now.

Supporting development

I do all development on PyObjC in my spare time. Please consider donating if 
you use PyObjC professionally. This will help me to improve PyObjC and related 
projects. See my website for more information.


P.S. This is a cross-post from 
http://blog.ronaldoussoren.net/2018/09/18/pyobjc-is-out.html, and I’ve also 
tweeted about this from @RonaldOussoren.

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] [ANN] PyObjC 5.0b1

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I just uploaded PyObjC 5.0b1 to PyPI. This is the first beta of the version of 
PyObjC that includes support for macOS 10.14 (Mojave). I expect to release 5.0 
soon after the GM release of Xcode 10. 

The primary new “feature” as compared with the 5.0a1 is that this release 
includes binary wheels for all supported versions of Python (2.7, 3.4, 3.5, 3.6 
and 3.7, and for 2.7, 3.6 and 3.7 there are wheels for both the older “intel” 
installer and the newer 64-bit installer on Python.org) 

Changes w.r.t. PyObjC 5.0a1:

* Bindings updated for Xcode 10 beta 6.

* Add a custom binding for a number of structure types in
  CoreAudio:

  - AudioBuffer
  - AudioBufferList
  - AudioChannelDescription
  - AudioChannelLayout
  - AudioValueTranslation

  With this patch using APIs with these types should actually
  work.

* PR19: Fix deprecation warning in bridgesupport support module

  Patch by: Mickaël Schoentgen

* Creating objc.ObjCPointer instances now results in a
  Python warning, instead of an unconditional message on
  stdout.

  .. note::

 The creation of these objects is a sign that APIs are
 not wrapped correctly, these objects are created for
 pointers where the bridge doesn't know how to handle
 them properly.

* System bridgesupport XML files (normally not used by PyObjC)
  can contain constant numbers with value "inf", PyObjC now
  knows how to handle those.

* Added bindings for the "Metadata" subframework of the
  "CoreServices" framework.

* Added bindings for the "CarbonCore" subframework of the
  "CoreServices" framework.

  Most APIs in this subframework are not available to Python,
  only those APIs that are not deprecated and seem interesting
  are exposed.

* The separate framework wrappers DictionaryServices,
  LaunchServices and SearchKit are deprecated, use
  the CoreServices bindings instead.

  These framework wrappers still exists, but are effectively
  aliases for CoreServices with this release. Because of this
  these bindings can expose more symbols than previously.

* Fix unexpected exception when trying to call getattr
  on a framework wrapped with a name that isn't a valid
  identifier.

* #244: Bad metadata for CGPDFOperatorTableSetCallback

* #247: Fix crash in regression test case

  One specific test in pyobjc-core crashed the interpreter
  when run separately. Because of this I've disabled an
  optimization that uses alloca instead of PyMem_Malloc to
  allocate memory for now.


Regards,

  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

[Pythonmac-SIG] [ANN] py2app 0.16 and macholib 1.11

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I’ve released py2app 0.16 and macholib 1.11 with a couple of small changes.

The most important fix is in macholib and avoids the "New Mach-O header is too 
large to relocate in …” error when using Python wheels containing shared 
libraries (such as Pillow).



A full list of changes in py2app 0.16:

* #244: Copy the Tcl/Tk support libraries into the application bundle for
  Python builds using a classic unix install of Tcl/Tk instead of a framework
  build.

  This results in working app bundles when a Python.org installation that
  includes Tcl/Tk (such as Python 3.7).

* Don't copy numpy into application just because the application uses
  Pillow.

* Add recipe for Pyside

  Patch by Alberto Sottile

And macholib 1.11:

* Add very hacky limited support for @loader_path. This is just
  enough to deal with extensions and dylibs found in Python
  binary wheels.


Regards,

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

[Pythonmac-SIG] [ANN] First alpha release for PyObjC 5.0

[Ronald Oussoren via Pythonmac-SIG]

[This is a cross-post from http://blog.ronaldoussoren.net]

I pushed a first alpha release for PyObjC 5.0 to PyPI, it can be installed with 
“pip install –pre pyobc”.

The major change in the 5.0 release is the addition of API bindings for macOS 
10.14. This release is mostly up-to-date w.r.t. developer beta 3 of that 
release.

Other than updating existing API bindings this release adds new framework 
bindings for the following frameworks:

• AdSupport
• CoreAudio (new in macOS 10.0)
• CoreAudioKit (new in macOS 10.4)
• CoreMedia (new in macOS 10.7)
• CoreMediaIO (new in macOS 10.7)
• DiscRecording (new in macOS 10.2)
• DiscRecordingUI (new in macOS 10.2)
• DVDPlayback (new in macOS 10.3)
• MediaToolbox
• NaturalLanguage
• Network
• OSAKit (new in macOS 10.4)
• UserNotifications
• VideoSubscriberAccount

The bindings for CoreAudio, CoreMedia and MediaToolbox aren’t fully usable in 
this release, I have to write C code for a number of APIs and data structures 
that cannot be accessed using the generic FFI in pyobjc-core.

This alpha release only included wheels for the 64-bit installer of Python 3.7 
(the default download on Python.org), the final release will include the full 
set of wheels.

Footnote

The release is a week later and less complete than I had hoped earlier. The 
reason for that is primarily that I was too optimistic on the amount of work 
I’d be able to do before and during EuroPython. In the end I barely touched my 
computer for PyObjC work at EuroPython, and not at all during the trip around 
Scotland beforehand (both of which were good for me, but less so for making 
progress)

Regard,

  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

Re: [Pythonmac-SIG] py2app is not finding imported libraries

[Ronald Oussoren via Pythonmac-SIG]

Could you create a small reproducer and sent me it as well as the output of 
“python3 setup.py py2app -A”, the output of “python3 -mpip list” and a list of 
files in the generated app bundle (in a Terminal window: find dist/MyApp.app 
-ls)? With some luck this will help me find the issue. 

And just to avoid the obvious problem: does importing both libraries work when 
you don’t use py2app? 

And finally some questions about the python installation:
* How did you install Python 3.5.2?  (Python.org  
installer, homebrew, …)
* Have you installed other Python versions (such as 3.6 or 3.7)? 

Ronald

> On 27 Jul 2018, at 18:56, David Simmons  wrote:
> 
> Do not know where else to seek help as I have extensively searched for months 
> on the internet without finding a hint to fix the problem.
> 
> I am using Apple OS X 10.13.6 and Python 3.5.2.  All attempts to use py2app 
> with the -A option and without fail to find PyQT4 and reportlab libraries.  I 
> use tinter for the GUI and reportlab to write PDF’s.
> 
> Any clue on how to solve this problem would be greatly appreciated.
> 
> NOTE:  py2app was working fine before and then started failing.
> 
> David Simmons
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] ANN: py2app 0.15

[Ronald Oussoren via Pythonmac-SIG]

Hi,

I just pushed py2app 0.15 to PyPI. This has basically one change from the 
previous release: This release supports Python 3.7.

There are also updates to altgraph, modulegraph and macholib that should get 
automatically installed 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

[Pythonmac-SIG] Towards PyObjC 5.0

[Ronald Oussoren via Pythonmac-SIG]

Hi,

Just a quick message about development on PyObjC 5.0.  The process of updating 
PyObjC for macOS 10.14 is going faster than expected, although it has helped 
that I took time of from work during WWDC to work on this.

I expect to push out a first beta release of PyObjC 5 during the EuroPython 
2018 sprints. This release should be feature complete (barring surprises in 
future SDK betas). 

This is turning out to be a major milestone for PyObjC: with some luck PyObjC 
5.0 will support almost all public frameworks in macOS, with the exception of 
deprecated frameworks that aren’t already wrapped and the Metal frameworks 
(Metal and MetalPerformanceShaders).

Major items on my TODO list until then:
- Finish a number of bindings that require manual wrappers due to APIs that are 
too complex to expres correctly in metadata files
- Work on support for APIs that have SIMD types as arguments or return values 
(such as vector_float3 in ObjC)
- Work on providing DeprecationWarnings for APIs that are deprecated in macOS. 
The basic framework for this is present, I “just” have add correct metadata for 
this.

Beyond 5: My current plan is that PyObjC 5 will be the last version of PyObjC 
that supports Python 2.7 and PowerPC. 

I have not yet decided on 32-bit x86 support, that might be dropped as well (at 
least in the released binaries). Dropping support for 32-bit x86 would 
primarily make it easier to provide wheels, as the compiler tools in Xcode 10 
no longer support that architecture.

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

[Pythonmac-SIG] Python bindings for Metal?

[Ronald Oussoren]

Hi,

Does anyone know of Python bindings to Apple’s Metal, and related, 
framework(s)?  I’m particularly interested in the compute parts (basically in 
the Metal equivalent of OpenCL).

I’ve search around a bit on PyPI and using Google, but haven’t found anything 
yet. 

Ronald

P.S. I’m interested in experimenting with Metal, but at this time not enough so 
to spend a lot of time in first creating bindings. 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] PyObjC 4.2.2

[Ronald Oussoren]

Hi,

I’ve pushed PyObjC 4.2.2 to PyPI. This is a very minor bug fix release that 
I’ve pushed out to clear the queue before WWDC.

There is one new feature with this release: There are now two variants of the 
binary wheels for Python 3.6 and 3.7, both now have variants for the universal 
build for macOS 10.6 or later (i386 and x86_64) as well as the 64-bit build for 
macOS 10.9 or later. 

Next up is support for the macOS release beyond High Sierra. I expect that this 
will take quite some time, especially w.r.t. updating the framework wrappers. 

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

[Pythonmac-SIG] ANN: PyObjC 4.2.1

[Ronald Oussoren]

Hi,

I just pushed PyObjC 4.2.1 to PyPI. This is a very minor bug fix release and 
most people don’t have to upgrade. 

There’s only a single fix for some people from source: the automatic detection 
of the use of “—with-system-ffi” works again (it was disabled in 4.2 because 
that feature didn’t work with /usr/bin/python).

The fix doesn’t affect users of binary wheels.

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

Re: [Pythonmac-SIG] Argument is a block, but no signature available

[Ronald Oussoren]

> On 16 Mar 2018, at 20:39, Ben Byram-Wigfield  wrote:
> 
> I’m trying to use a Completion Handler block as an argument for a Cocoa 
> AVMIDIPlayer method:
> 
> midiPlayer = 
> AVMIDIPlayer.alloc().initWithContentsOfURL_soundBankURL_error_(midiFile, 
> None, None)
> midiPlayer.prepareToPlay()
> midiPlayer.play_(myCompletionHandler)
> 
> But I get:
> 
> Argument 2 is a block, but no signature available
> 
> From what I can find out, this points to a bit in the metadata of PyObjC that 
> needs a bit of work. Is that the case?

That’s correct.

> 
> I’m using the default version 2.5.1 bundled with MacOS.

That’s your problem, 2.5 is ancient and unmaintained.  I’ve checked the 
metadata for PyObjC 4.2 (released yesterday) and that has metadata for this API.

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

[Pythonmac-SIG] ANN: PyObjC 4.2

[Ronald Oussoren]

I’ve just published PyObjC 4.2 on PyPI. This is primarily a bug fix release, 
but also introduces bindings to the BusinessChat framework introduced in macOS 
10.13.4.  Those bindings are probably totally uninteresting for most users as 
the framework can only be used by a small subset of macOS developers. 

The full list of changes for this release:

* Add bindings to the BusinessChat framework introduced in macOS 10.13.4

* Update metadata for Xcode 9.3

* Issue #233 Fix crash in Security.AuthorizationCopyRights() wrapper

* Issue #234 Fix crash in AuthorizationExecuteWithPrivileges() wrapper

  Reported by Vangelis Koukis

* Ensure doctest can work with modules containing subclasses of NSObject

  Reported by Just van Rossum

* Issue #236 : Importing can sometimes fail in multi-threaded scenarios

  Fix by Max Bélanger

* Undeprecate treating struct wrappers as sequences. Removing this feature would
  break too much existing code, hence deprecating is not really an option. 
Furthermore,
  this would also break some nice idioms.


* Pull request #17: Fix python 3 issues in PyObjCTools.AppHelper and 
PyObjCTools.Conversion

  Fix by Max Bélanger


Regards,

  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

[Pythonmac-SIG] ANN: PyObjC 4.0.1

[Ronald Oussoren]

Hi,

I just uploaded PyObjC 4.0.1 to PyPI. This is a minor update to PyObjC 4.0, the 
changelog for this release is included below

Version 4.0.1
-

* Issue #213: Fix signature for ```-[NSObject forwardInvocation:]```

  Reported by user "pyrocat"

* Updated metadata for Xcode 9.1

* Changes to PyObjCTools.TestSupport to be able to include/exclude tests
  based on the minor release of macOS.

* Some tweaks to fix test failures when running on OSX 10.5, 10.6, 10.9.


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

[Pythonmac-SIG] ANN: PyObjC 4.0

[Ronald Oussoren]

Hi,

I’m happy to announce PyObjC 4.0.  The major difference in this release is 
support for new APIs and frameworks introduced in macOS 10.13 (High Sierra).  A 
minor change is that the documentation is now on readthedocs: 
>

The release notes > contain more detailed 
information on what has changed.

And finally a technical note: this release was cut from the macos10.13-support 
branch of the repository, I haven’t merged the branch back into default yet.

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

[Pythonmac-SIG] Tkinter and PyObjC

[Ronald Oussoren]

Hi,

I’m kind of hoping that a Tkinter or Tk expert is reading this…

A PyObjC user tries to call Tkinter from a Cocoa program (that is, the Cocoa 
runloop starts before the Tkinter one) and gets an error message:

-[NSApplication _setup:]: unrecognized selector sent to instance

Furthermore the Tkinter GUI doesn’t work. PyObjC’s issue about this: 


https://bitbucket.org/ronaldoussoren/pyobjc/issues/201/tkinter-method-tk-failed-with-error

I’ve done some quick browsing of the Tk source code and it appears that Tk 
assumes that -[NSApplication sharedApplication] returns an instance of a 
Tk-specific private subclass of NSApplication and that won’t be true when the 
Tk runloop is started before the Cocoa one.

My question: is my analysis correct? And has anyone successfully mixed PyObjC 
and Tkinter in this way? I guess this issue could be avoided by initialising Tk 
before calling into Cocoa.

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

[Pythonmac-SIG] PyObjC 4.0b1

[Ronald Oussoren]

Hi,

I’ve uploaded a test release of PyObjC to PyPI: PyObjC 4.0b1.

The major difference with the previous release on PyPI is support for APIs 
introduced in macOS 10.13, which is why this is a beta release. I’ll push out a 
final release once 10.13 is released.  The beta also fixes a number of bugs 
(all of which are also fixed in the default branch, but I haven’t cut a release 
from that).

A related beta of the documentation is at Read the Docs: 
http://pyobjc.readthedocs.io . It contains the 
same documentation, as before, but now generated directly from the main 
repository which should make updating the documentation a lot easier.

BTW. Updating the framework bindings has been a lot of work, but recent beta’s 
for Xcode had very few changes. I expect almost no updates to the framework 
bindings between this beta and the final release. 

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

Re: [Pythonmac-SIG] PyObjC - Apple sample code

[Ronald Oussoren]

> On 2 May 2017, at 13:47, Ben Byram-Wigfield <ben...@me.com> wrote:
> 
> I reinstalled python 2.7.13 from a fresh downloaded .pkg, and used pip to 
> reinstall PyObjC, but I still get the same errors.
> Do the Quartz example scripts work on python 3 ?

The example work with  both python 3 and python 2.7.

Ronald

> 
> Ben
> 
>> On 29 Apr 2017, at 05:57, Christopher Barker <python...@gmail.com 
>> <mailto:python...@gmail.com>> wrote:
>> 
>> And you really don't want to use easy_install amymore, either. Try pip.
>> 
>> I see the appeal of an Apple-supplied python, but Apple has never properly 
>> supported it ever since OS-X 10.1.
>> 
>> -CHB
>> 
>> 
>> 
>> 
>> On Fri, Apr 28, 2017 at 5:19 PM Glyph <gl...@twistedmatrix.com 
>> <mailto:gl...@twistedmatrix.com>> wrote:
>> Relying on the system Python for this sort of stuff has always guaranteed 
>> you'd have an out-of-date version of all of your dependencies.
>> 
>> The availability of wheels (thanks again Ronald!!!) for pyobjc means that 
>> you don't need the biggest impediment to users installing stuff, which is a 
>> C compiler.  If you're building stuff for distribution to non-technical 
>> folks, build it with your own version of python (3) and ship it with py2app, 
>> not by copying scripts around.
>> 
>> If there are things that make this more painful than just copying individual 
>> scripts, it's probably best to figure out how to get those addressed with 
>> the PyPA community.
>> 
>> -glyph
>> 
>> > On Apr 28, 2017, at 4:20 AM, Ben Byram-Wigfield <ben...@me.com 
>> > <mailto:ben...@me.com>> wrote:
>> >
>> > I ran the installer package for the latest python 2.7, and then used 
>> > easy_install to install PyObjC.
>> > I get the same errors on two separate Macs. What should I do to fix the 
>> > installation?
>> >
>> > Does Apple not have plans to include (all of) the latest PyObjC? That’s 
>> > rather sad. The reason I was attracted to creating ObjC python scripts was 
>> > that they could run on any Mac.
>> >
>> > Thanks
>> >
>> > Ben
>> >
>> >
>> >> On 28 Apr 2017, at 08:07, Ronald Oussoren <ronaldousso...@mac.com 
>> >> <mailto:ronaldousso...@mac.com>> wrote:
>> >>
>> >>
>> >>> On 27 Apr 2017, at 10:17, Ben Byram-Wigfield <ben...@me.com 
>> >>> <mailto:ben...@me.com>> wrote:
>> >>>
>> >>> I tried the repository browser there, and the version of 
>> >>> parse_page_contents.py still doesn’t work for me. I’m using the latest 
>> >>> downloaded versions of python 2.7 and PyObjC. I also tried using the 
>> >>> default OS X versions.
>> >>> The errors are in the attached file.
>> >>>
>> >> The PyObjC 3.2 error at the top of the file seems to indicate that your 
>> >> Python installation is broken, PyObjC imports the stdlib io module and 
>> >> that causes and error.
>> >>
>> >> The PyObjC 2.5 error is due to general brokeness of the system 
>> >> installation of PyObjC. PyObjC 2.5 is ancient and not something I support 
>> >> anymore, furthermore (IIRC) Apple doesn’t ship all of PyObjC. The error 
>> >> you’re getting indicates that the framework wrappers are incomplete.
>> >>
>> >> BTW. If you are new to Python I’d look into using Python 3.6 instead, 
>> >> both because that has less change to run into problems due to 
>> >> interference between the system install of Python 2.7 and a manual 
>> >> installation, and because the Python community is moving ever faster to 
>> >> Python 3.
>> >>
>> >> Ronald
>> >>
>> >
>> > ___
>> > Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
>> > <mailto:Pythonmac-SIG@python.org>
>> > https://mail.python.org/mailman/listinfo/pythonmac-sig 
>> > <https://mail.python.org/mailman/listinfo/pythonmac-sig>
>> > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
>> > <https://mail.python.org/mailman/options/Pythonmac-SIG>
>> ___
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
>> <mailto:Pythonmac-SIG@python.org>
>> https://mail.python.org/mailman/listinfo/pythonmac-sig 
>> <https://mail.python.org/mailman/listinfo/pythonmac-sig>
>> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
>> <https://mail.python.org/mailman/options/Pythonmac-SIG>
>> -- 
>> Christopher Barker, PhD
>> 
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC - Apple sample code

[Ronald Oussoren]

> On 27 Apr 2017, at 10:17, Ben Byram-Wigfield  wrote:
> 
> I tried the repository browser there, and the version of 
> parse_page_contents.py still doesn’t work for me. I’m using the latest 
> downloaded versions of python 2.7 and PyObjC. I also tried using the default 
> OS X versions.
> The errors are in the attached file.
> 
The PyObjC 3.2 error at the top of the file seems to indicate that your Python 
installation is broken, PyObjC imports the stdlib io module and that causes and 
error.

The PyObjC 2.5 error is due to general brokeness of the system installation of 
PyObjC. PyObjC 2.5 is ancient and not something I support anymore, furthermore 
(IIRC) Apple doesn’t ship all of PyObjC. The error you’re getting indicates 
that the framework wrappers are incomplete.

BTW. If you are new to Python I’d look into using Python 3.6 instead, both 
because that has less change to run into problems due to interference between 
the system install of Python 2.7 and a manual installation, and because the 
Python community is moving ever faster to Python 3.

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

Re: [Pythonmac-SIG] PyObjC - Apple sample code

[Ronald Oussoren]

> On 22 Apr 2017, at 10:45, Ben Byram-Wigfield  wrote:
> 
> I’ve been looking at Apple’s Open Source website, where there is lots of 
> python sample code. But the examples I’ve tried don’t work. They all flag 
> syntax errors (usually about type conversion), or occasionally make the 
> python process crash!
> 
> Particularly, I’m looking at a script to parse the contents of a PDF file. 
> There are a few slightly different versions (and I don’t understand all the 
> different folders — pyobj 14, 26, 47, 49???)
> 
> https://opensource.apple.com/source/pyobjc/pyobjc-49/pyobjc/pyobjc-framework-Quartz-2.5.1/Examples/Programming%20with%20Quartz/ParsePageContents/parse_page_contents.py
>  
> 
> 
> https://opensource.apple.com/source/pyobjc/pyobjc-14.1.1/pyobjc/stable/pyobjc-framework-Quartz/Examples/Programming%20with%20Quartz/ParsePageContents/parse_page_contents.py
>  
> 
> 
> But none of them work. I’ve tried them on PyObjc 2.5.1 and 3.2.1, which gives 
> different syntax errors. (Question 2, why does OS X ship with only 2.5.1?)
> 
> I’ve scoured the internet for better examples of python-quartz-pdf_parsing, 
> but not found anything. The Apple Dev Forums suggested that the code wasn’t 
> maintained by Apple, but by PyObjC.

See http://pyobjc.sf.net/ , which contains all current 
examples and those should work with the current release of PyObjC and python 
2.7 and 3.x.

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

[Pythonmac-SIG] py2app 0.12 and modulegraph 0.14 released

[Ronald Oussoren]

Hi,

I’ve just pushed py2app 0.12 and modulegraph 0.14 to PyPI. Both primarily 
contain bugfixes.

I had hoped to fix more issues in these releases, but that hasn’t worked out 
and the fixed bugs are serious enough to not delay the release any more. On to 
the next release…

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

Re: [Pythonmac-SIG] Prevent python install editing .bash_profile

[Ronald Oussoren]

> On 2 Feb 2017, at 15:43, Barry Scott <ba...@barrys-emacs.org 
> <mailto:ba...@barrys-emacs.org>> wrote:
> 
>> 
>> On 31 Jan 2017, at 21:19, Barry Scott <ba...@barrys-emacs.org 
>> <mailto:ba...@barrys-emacs.org>> wrote:
>> 
>> 
>>> On 31 Jan 2017, at 21:08, Ronald Oussoren <ronaldousso...@mac.com 
>>> <mailto:ronaldousso...@mac.com>> wrote:
>>> 
>>> 
>>>> On 28 Jan 2017, at 17:42, Barry Scott <ba...@barrys-emacs.org 
>>>> <mailto:ba...@barrys-emacs.org>> wrote:
>>>> 
>>>> Is it possible to prevent the editing of the shell profile when I install 
>>>> a python kit?
>>>> 
>>>> I keep having to delete the, unnecessary for me, PATH editing.
>>> 
>>> The installer has an option for not updating the shell profile: after the 
>>> “select a destination” screen you can choose “customize”, on that screen 
>>> unselect “shell profile updater”.
>> 
>> O.k. I will use that when I update again.
> 
> Given that /usr/local/bin is on the PATH (as it is in /etc/paths) and the 
> installer links python pip etc into /usr/local/bin
> why does it need to edit my .bash_profile at all with the long 
> /Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6
> paths.
> 
> Is this a hang over from older macOS versions?

I’m not 100% sure, /usr/local may not have been in the default PATH in the past 
and if it were it would have been after /usr/bin which is problematic when 
trying to use a Python.org <http://python.org/> install of the same python 
version as is included in macOS.

A more important reason is that when you install additional software into the 
global installation any scripts will get installed in the directory 
/Library/Frameworks/…/bin and not in /usr/local. It could have been possible to 
coax distutils to install scripts into /usr/local, but then you run into 
problems when running multiple python versions.

I generally install with neither updating the shell profile nor installing 
links in /usr/local, that keeps the global system clean (and I have some custom 
shell profile code to keep python frameworks on PATH in the order I like).

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

Re: [Pythonmac-SIG] Prevent python install editing .bash_profile

[Ronald Oussoren]

> On 28 Jan 2017, at 17:42, Barry Scott  wrote:
> 
> Is it possible to prevent the editing of the shell profile when I install a 
> python kit?
> 
> I keep having to delete the, unnecessary for me, PATH editing.

The installer has an option for not updating the shell profile: after the 
“select a destination” screen you can choose “customize”, on that screen 
unselect “shell profile updater”.

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

Re: [Pythonmac-SIG] apple-Python and TLS 1.0

[Ronald Oussoren]

> On 10 Jan 2017, at 20:43, Ronald Oussoren <ronaldousso...@mac.com> wrote:
> 
> 
>> On 10 Jan 2017, at 17:05, Jack Jansen <jack.jan...@cwi.nl> wrote:
>> 
>> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate 
>> until know, but just now the following post came in on python-announce, 
>> which seems to suggest that TLS 1.0 is really about to be phased out: 
>> https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html
>> 
>> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped 
>> Pythons) don’t support TLS 1.2 by default, which would seem to suggest that 
>> things like pip will stop working as of this summer.
>> 
>> Or am I overreacting?
> 
> You are not. Annoyingly Donald Stufft already noticed that Apple’s Python is 
> problematic, but breaking for users on a major OS is apparently not a problem 
> :-(

Breaking Python tools is probably not really on Fastly’s radar and not 
something that the PyPI folks can easily avoid.

> 
> This shouldn’t be a problem for most serious development as those users 
> likely use a separate python installation anyway, but this will affect casual 
> users including at least some new users. 

BTW. This doesn’t just break /usr/bin/python but also the Python.org 
<http://python.org/> installation of 2.7 (including 2.7.13), and likely any 
Python.org <http://python.org/> install exception 3.6 as  all installers upto 
3.6 use the system OpenSSL that doesn’t support anything beyond TLS 1.0.

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

Re: [Pythonmac-SIG] apple-Python and TLS 1.0

[Ronald Oussoren]

> On 10 Jan 2017, at 17:05, Jack Jansen  wrote:
> 
> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate 
> until know, but just now the following post came in on python-announce, which 
> seems to suggest that TLS 1.0 is really about to be phased out: 
> https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html
> 
> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped 
> Pythons) don’t support TLS 1.2 by default, which would seem to suggest that 
> things like pip will stop working as of this summer.
> 
> Or am I overreacting?

You are not. Annoyingly Donald Stufft already noticed that Apple’s Python is 
problematic, but breaking for users on a major OS is apparently not a problem 
:-(

This shouldn’t be a problem for most serious development as those users likely 
use a separate python installation anyway, but this will affect casual users 
including at least some new users. 

Ronald

> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed

[Ronald Oussoren]

> On 10 Jan 2017, at 17:00, Barry Scott  wrote:
> 
> Ronald,
> 
> Attached is a patch that cleans up the false positives by allows the recipes 
> to tell build_app what is expected to be missing.
> 
> I can turn into a pull request if you like the direction of this patch.

I like the idea.. A pull request for this would be nice.

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

Re: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed

[Ronald Oussoren]

On 27 Dec 2016, at 22:38, Chris Barker <chris.bar...@noaa.gov> wrote:On Tue, Dec 27, 2016 at 11:36 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote:As an aside to this: I’m considering to remove the site-packages.zip file from the app bundle and store everything outside off zipfiles. A lot of code works inside zipfiles, but there are too many exceptions and with the transition from eggs to wheels even less packages will care to document whether or not they work with their code in zipfiles. I think this is a good idea -- these days, size really only matters when you're shipping the app, not when it's on disk (or SSD) -- so why bother with the zip?Speed (loading from zipfiles tends to be slightly faster), and slightly fewer opportunities of other tools to mess up.  People also tend to like the fact that code is more hidden from users.  > I have an issue about copying enough information into the application to ensure pkg_resources.require works, but haven’t gotten around to doing the work for that because I don’t need the feature myself. AFAIK pkg_resources should work for accessing datafiles though. Could you file a bug for the pytz problem on py2app’s tracker? pkg_resources is a pain in general, and particularly always has been with py2app and the like.That’s not my experience, and I’ve tried to ensure that using pkg_resources to access resources in the current python package would work as that solves the problem w.r.t. zipping data files for at least some packages.but I've usually gotten it to work OK by explicitly listing the package to be included, so that py2app will bundle the whole thing.I generally consider the need to explicitly list packages to be included as a bug in py2app, that is I strive to make py2app comprehensive enough to automatically include enough stuff in the app bundles.  Py2app obviously isn’t anywhere near that at the moment :-(It seems that py2app will package up all the files in a package, not just the.py files. Is that the algorithm that is used?That’s correct. All files in the directory of a python package are assumed to be important. which is why it usually works OK for things like pytz. :-(That’s intentional.-CHB-- Christopher Barker, Ph.D.OceanographerEmergency Response DivisionNOAA/NOS/OR            (206) 526-6959   voice7600 Sand Point Way NE   (206) 526-6329   faxSeattle, WA  98115       (206) 526-6317   main receptionchris.bar...@noaa.gov

--Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___Pyobjc-dev mailing listpyobjc-...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/pyobjc-dev___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed

[Ronald Oussoren]

> On 21 Dec 2016, at 00:02, Barry Scott <ba...@barrys-emacs.org> wrote:
> 
>> 
>> On 18 Dec 2016, at 20:39, Ronald Oussoren <ronaldousso...@mac.com 
>> <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> Hi,
>> 
>> I had hoped to release a new version of py2app today, but didn’t due to 
>> problems with macholib that resulted in broken application bundles. The good 
>> news is that I found the cause of that breakage and reverted the patch that 
>> caused it.
>> 
>> I did fix a number of bugs on the tracker last week (the number of open 
>> issues decreased from 94 to 72), and implemented a useful new feature: 
>> support for “@loader_path” in shared libraries, which is used in wheels 
>> processed with delocate 
>> <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py
>>  
>> <https://github.com/matthew-brett/delocate/blob/master/delocate/delocating.py>>
>>  such as the wheels for Pillow.
>> 
>> Because this is turning into a fairly large release I’d appreciate if people 
>> could test the code in the repository with their applications. To install 
>> first install altgraph-0.13, then install modulegraph, macholib and py2app 
>> from their bitbucket repositories 
>> (https://bitbucket.org/ronaldoussoren/modulegraph 
>> <https://bitbucket.org/ronaldoussoren/modulegraph>, 
>> https://bitbucket.org/ronaldoussoren/macholib 
>> <https://bitbucket.org/ronaldoussoren/macholib> and 
>> https://bitbucket.org/ronaldoussoren/py2app 
>> <https://bitbucket.org/ronaldoussoren/py2app>).
>> 
>> There’s still a fairly large number of open issues for py2app, but those 
>> will have to wait for a later time (which hopefully be a lot sooner than the 
>> time it took me to get from the previous release to this point).
>> 
> 
> Thanks for working on an update. I know you time is limited, however I hope 
> you can comment on these questions about py2app.
> I was looking at contributing patches but found, as you did that macholib was 
> very broken so gave up patching and hacked workarounds.
> 
> I’m using py2app to package a couple of apps that use PyQt and pytz.
> 
> I found that the resulting app  has the .dylib files in the python35.zip.
> Is that correct? I had assumed that .dylib files need to be in the .app
> as files, is there a trick to run them out of the .zip file?

That’s not supposed to happen. Are the dylibs part of a python package? If so, 
are these loaded by C extensions or included as data files (for example because 
ctypes is used to load the dylib)? 

A bug report on bitbucket with a sample project that demonstrates the problem 
would be appraised. I cannot promise that I’ll promptly fix the issue, but a 
sample project would make fixing this a lot easier.

As an aside to this: I’m considering to remove the site-packages.zip file from 
the app bundle and store everything outside off zipfiles. A lot of code works 
inside zipfiles, but there are too many exceptions and with the transition from 
eggs to wheels even less packages will care to document whether or not they 
work with their code in zipfiles. 

> 
> I have been copying in the PyQt .dylib, plugins etc into the .app with
> a script that adds these in Contents/Frameworks etc after fixing up the 
> RPATHs.
> 
> For pytz to work in a py2app .app pkg_resources needs to work and it
> does not. Is this a known issue? I worked around it with a stub pkg_resources
> package that reached into the python35.zip and pulled out the zoneinfo files.

I have an issue about copying enough information into the application to ensure 
pkg_resources.require works, but haven’t gotten around to doing the work for 
that because I don’t need the feature myself. 

AFAIK pkg_resources should work for accessing datafiles though. Could you file 
a bug for the pytz problem on py2app’s tracker? 

> 
> It seems that py2app will package up all the files in a package, not just the
> .py files. Is that the algorithm that is used?

That’s correct. All files in the directory of a python package are assumed to 
be important. 

BTW.  None of these fixes will be in the next release of py2app, but I really 
hope to find a way to do more py2app maintenance next year (instead of 
basically just doing so during vacations). 

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

[Pythonmac-SIG] py2app release delayed

[Ronald Oussoren]

Hi,

I had hoped to release a new version of py2app today, but didn’t due to 
problems with macholib that resulted in broken application bundles. The good 
news is that I found the cause of that breakage and reverted the patch that 
caused it.

I did fix a number of bugs on the tracker last week (the number of open issues 
decreased from 94 to 72), and implemented a useful new feature: support for 
“@loader_path” in shared libraries, which is used in wheels processed with 
delocate 
> 
such as the wheels for Pillow.

Because this is turning into a fairly large release I’d appreciate if people 
could test the code in the repository with their applications. To install first 
install altgraph-0.13, then install modulegraph, macholib and py2app from their 
bitbucket repositories (https://bitbucket.org/ronaldoussoren/modulegraph 
, 
https://bitbucket.org/ronaldoussoren/macholib 
 and 
https://bitbucket.org/ronaldoussoren/py2app 
).

There’s still a fairly large number of open issues for py2app, but those will 
have to wait for a later time (which hopefully be a lot sooner than the time it 
took me to get from the previous release to this point).

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

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 15 Dec 2016, at 21:41, Cosimo Lupo  wrote:
> 
> +1 on having the official Python.org distribution be a standalone Python.app 
> that users could just drag-and-drop like with the rest of native non-AppStore 
> apps!

A Python.app from python.org  should be a long term plan at 
best, it would be better to start work on this outside of constraints of 
CPython (e.g. not being able to use libraries outside of the stdlib and only 
shipping feature updates with major releases). 

> 
> (I wish Apple shipped macOS with Python 3…)

I’ve mixed feelings about that, on the one hand having Python 3 available by 
default would be cool, but on the other hand you’d have to rely on Apple to 
keep that software up to date and Apple tends to only ship security updates 
between major releases. That’s not too bad for Python 2.7, but is less useful 
for 3.x.

> 
> And thanks a lot Ronald for the PyObjC wheels on PyPi :D

That turned out to be a lot less work than I expected, I should have done the 
work a long time ago ;-)

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

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 15 Dec 2016, at 07:25, Christopher Barker  wrote:
> 
> On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz  > wrote:
> 
>> On Dec 14, 2016, at 9:44 AM, Chris Barker > > wrote:
>> 
>> conda also has a non-framework build of Python -- not sure if that would 
>> cause any issues with the wheels.
> 
> I am not up on all the technical specifics, but this suggests to me that 
> Conda would be generally unsuitable for use as a Mac native development 
> environment, and hence not a Python you'd want to use pyobjc with.
> 
> If you don't have a framework build, you don't have an app bundle;
> 
> in the standard python.org  builds, the Framework Build 
> provides an app bundle. But having python in a Framework is completely 
> orthogonal to the App BUndle issue.
> 
> Yes, you need the executable to be in an app bundle in order to access the 
> Window manager (and who knows what else), but again, that has nothign to do 
> with the Framework Build.
> 
> unfortunately, the build scripts only have a couple ready-to-go options, so 
> to get the app bundle executable, you do need the Framework build.
> 
> I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's 
> no good reason for a Framework build at all -- it just seemed like the 
> Apple-y way to do it at the time, and now we have the legacy.

IIRC the framework build was initially created for NextStep, and was updated 
for Mac OS X when that came out (and later tweaked to support fat binaries). A 
framework was the right way to integrate into the OS at the time, and IMHO 
still is a good choice w.r.t. platform integration. 

Frameworks have the nice feature that everything related to the framework is 
stored in a single location, with proscribed location for that location. This 
is especially useful when doing side-by-side installation of Python 2 and 
Python 3, those naturally get different locations for their binaries which 
avoids conflicts when installing scripts into both of them.

> 
> 
> However, conda has supplied an app bundle version, which you can install with:
> 
> conda install python.app
> 
> it supplies a "pythonw" script that bootstraps s python inside a app bundle 
> and can run GUI apps -- I know it works fine with wxPython, for instance.
> 
> Having to use pythonw is a kind of a pain -- and the ned for it was removed 
> years ago in the Framework builds -- those builds leverage a small executable 
> that bootstraps into an app bundle -- and works fine as a "regular" python 
> interpreter as well.
> 
> There's no reason we couldn't build that same executable outside a framework 
> -- someone just need to figure out the build scripts -- which i was hoping to 
> do last PyCon, but you can only get so much done in a 1-1/2 days of sprinting 
> -- plus I'm no build script expert. At All.

Building python.app + the launcher script outside of a framework should be 
easy, but I don’t understand why you’d want to do so as this will give you yet 
another way to deploy python on macOS.

BTW. In the longer run I’d love to see a binary distribution that’s just a 
Python.app with everything bundled inside, that would reduce the friction of 
installing python even further.  The main launcher of the app bundle could be a 
launcher for IDLE, possibly enhanced with a menu for installing symlinks to 
bundled executables/scripts into /usr/local/bin. 

Sadly enough distribution through the Mac Appstore isn’t really an option for 
this, the sandboxing requirements aren’t suitable for an IDE (as any script 
launched from the sandboxed IDE is also subjected to the sandbox restrictions, 
which isn’t very nice for users).

To get back on topic, PyObjC’s wheels should work fine with conda assuming it 
follows the platform defaults w.r.t. the size of unicode characters (for Python 
2.7).   I don’t test with conda though.

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

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 14 Sep 2016, at 00:28, Glyph Lefkowitz  wrote:
> 
> 
>> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe > > wrote:
>> 
>> But this is the framework (non-apple!) build!…
> 
> "framework build" refers to the way that Python is built.  Apple's python, 
> Python.org 's python, and Homebrew's python are all 
> framework builds.  So, to be clear: this is python.org  
> python?
> 
>> And, again: why isn’t everyone seeing this all the time? (And why didn’t I 
>> see it before?)
> 
> There's probably a .pth file somewhere that is stuffing Extras on your 
> sys.path.  easy_install (especially older versions) is notorious for creating 
> such things in ways that are hard to inspect for.  My usual recommendation at 
> this point is to blow away _everything_ in /Library/Python, ~/Library/Python, 
> ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then 
> reinstall from scratch.  (Thanks to SIP you don't need to blow away anything 
> in /System anymore; hooray!)

It should be enough to remove “/Library/Python” from the list of site packages 
in the non-system install of Python, it is added at the end of 
setsitepackages() in site.py. This should be done before running any code 
(particularly the ensurepip tool).  That would remove the directory containing 
the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and 
user provided stuff.   Doing this with the python.org installer requires some 
care, as it will by default run ensurepip during the installation (but this can 
be turned off).

According to issue 28440 /Library/Python/2.7/site-packages will no longer be 
treated as a site-packages directory in a future release of 2.7.

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

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Examples of vendoring python 3 with py2app

[Ronald Oussoren]

> On 11 Dec 2016, at 16:22, Cosimo Lupo  wrote:
> 
> Hello list,
> 
> Apologies if this is not the right place to ask about this.
> 
> I would like to distribute a self-contained OSX app of an application of mine 
> written in Python 3. I've used py2app in the past to ship apps written in 
> Python 2.7, that linked to the system Python framework.
> Now I'm wondering if I could if and how I could "vendor" Python 3.5 inside my 
> py2app-generated app.
> 
> In the py2app docs I could not find information as to how to embed the python 
> 3.5 interpreter and stdlib alongside the generated .app bundle.
> 
> Could anyone point me in the right direction, and/or link to existing open 
> source apps that do this?
> 
> Thank you for your help.

py2app will do that automatically unless you either explicitly tell it not to, 
or you use /usr/bin/python (the Apple provided installation of Python).

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

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2.1 released

[Ronald Oussoren]

> On 13 Dec 2016, at 04:02, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> 
> 
>> On Dec 12, 2016, at 1:25 AM, Ronald Oussoren <ronaldousso...@mac.com 
>> <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> Hi,
>> 
>> I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues 
>> in PyObjC 3.2, but the primary new feature is that there are now wheels on 
>> PyPI. 
>> 
>> I’ve tested the wheels on OSX 10.12 with the Python.org <http://python.org/> 
>> “intel” installers (the default download option for the OSX installers) and 
>> Homebrew. The wheels should also work fine with older OSX releases. 
> 
> Thank you *so* much, Ronald :D.  I installed pyobjc onto my laptop just now 
> and didn't even have to go get an icepack out of the freezer first :-).  In 
> under ten seconds, no less, for both python 3.5 and python 2.7.  A glorious 
> day, to be sure.
Great to hear that.

> 
> One minor note - I do notice that the 'pyobjc' package itself has no wheel, 
> even though all its dependents do.  Any chance you could upload 2.7/3.5 
> wheels for that as well?  It would just complete the set :-).

That is intentional. The setup.py for the package pyobjc calculates the 
“install_requires” list at runtime to ensure it will only install framework 
wrappers for frameworks that are actually present.  It might be possible to use 
conditional dependencies for that (see [1]), but I haven’t checked yet if those 
compare version numbers as structured data or strings.  PEP 426 seems to 
indicate they are just strings, and that would be less useful.   

I guess a wheel for the “pyobjc” package could just depend on all framework 
wrappers, that would install some code that isn’t relevant for the current 
machine but wouldn’t result in install failures (which could happen when 
installing all framework wrappers from source).  

Ronald

[1]: http://wheel.readthedocs.io/en/latest/#defining-conditional-dependencies
> 
> Thanks again; this is fabulous,
> 
> -glyph
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! 
> http://sdm.link/slashdot___
> Pyobjc-dev mailing list
> pyobjc-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] PyObjC 3.2.1 released

[Ronald Oussoren]

Hi,

I’ve just pushed PyObjC 3.2.1 to PyPI. This fixes a number of small issues in 
PyObjC 3.2, but the primary new feature is that there are now wheels on PyPI. 

I’ve tested the wheels on OSX 10.12 with the Python.org  
“intel” installers (the default download option for the OSX installers) and 
Homebrew. The wheels should also work fine with older OSX releases. 

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

Re: [Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> On 8 Dec 2016, at 23:55, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> 
>> 
>> On Dec 8, 2016, at 3:37 AM, Ronald Oussoren <ronaldousso...@mac.com 
>> <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> 
>>> On 8 Dec 2016, at 00:40, Glyph Lefkowitz <gl...@twistedmatrix.com 
>>> <mailto:gl...@twistedmatrix.com>> wrote:
>>>> 
>>>> 
>>>> 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.
>> 
>> I know how platform tags work, I’ve read the relevant PEPs when the were 
>> proposed. The “tweak” I wanted to use is documented as “Compressed Tag Sets” 
>> in PEP 425, and is how the python version is added to the wheel filename for 
>> wheels supporting both python2 and python3, as in:
>> 
>>pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl
>> 
>> This should work in the platform tag as well, and is already used by wheels 
>> for matplotlib (see https://pypi.python.org/pypi/matplotlib 
>> <https://pypi.python.org/pypi/matplotlib>).
> 
> Aah, I was reading you backwards.  I thought you were saying something about 
> inventing a platform tag for Homebrew (since they don't have one of their 
> own; they build specifically to be compatible with system python).  This 
> makes sense.

That explains the confusion.
> 
>>> 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.
>> 
>> I wrote the distutils code that sets the platform to a sane value for fat 
>> binaries on OSX ;-).  
> 
> Heh. I think we both know a little too much about this for our own good :-).
> 
>> That’s cool, this means pip did implement the logic that’s needed to 
>> understand that “intel” is an acceptable architecture when looking for a 
>> wheel for an “x86_64” build of CPython.
> 
> I believe it understands the tags pretty thoroughly; I haven't tested, but I 
> believe it also knows that an x86_64 wheel won't cut it on an 'intel' python 
> because it might blow up later.
> 
>>> 
>>> 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 :).
>> 
>> Looking at that page the relevant logic was added in pip 6, that’s old 
>> enough to not worry about using a compressed tag set for the platform. 
> 
> Cool.  I'm really looking forward to never building pyobjc again :-).

:-)

I’ve written some scripts to help me with doing the release, by scaling back 
the scope these scripts got a lot simpler and more importantly actually got 
written.  

Annoyingly the testsuite runner found some issues that I had missed before 
because I don’t regularly all python versions and architectures. The new test 
runner should make it a lot easier to do comprehensive testing, a test run will 
still take a lot of time but I won’t have to be present for that. 

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

Re: [Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> On 8 Dec 2016, at 00:40, Glyph Lefkowitz  wrote:
>> 
>> 
>> 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  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.

I know how platform tags work, I’ve read the relevant PEPs when the were 
proposed. The “tweak” I wanted to use is documented as “Compressed Tag Sets” in 
PEP 425, and is how the python version is added to the wheel filename for 
wheels supporting both python2 and python3, as in:

   pyobjc_framework_XgridFoundation-3.3a0-py2.py3-none-any.whl

This should work in the platform tag as well, and is already used by wheels for 
matplotlib (see https://pypi.python.org/pypi/matplotlib 
).

> 
> 
> 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.

I wrote the distutils code that sets the platform to a sane value for fat 
binaries on OSX ;-).  

> 
> 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.

That’s cool, this means pip did implement the logic that’s needed to understand 
that “intel” is an acceptable architecture when looking for a wheel for an 
“x86_64” build of CPython.

> 
> This is probably worth reading, as it explains the above in a lot more 
> detail: 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 :).

Looking at that page the relevant logic was added in pip 6, that’s old enough 
to not worry about using a compressed tag set for the platform. 

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

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.2 released puObjC

[Ronald Oussoren]

> On 7 Dec 2016, at 01:49, Christopher Barker <python...@gmail.com> wrote:
> 
> I haven't been involved for a while, but this gitHub org:
> 
> https://github.com/MacPython <https://github.com/MacPython>
> 
> Is doing a lot of wheel building, and I think they are using CIs to build and 
> test.
> 
> Maybe they could add pyObjC
> 
> Or you could see what they have set up.


They appear to use travis to build, with some script to sanitise binary 
dependencies (that is, copy non-system shared libraries into the wheel).  Might 
be interesting to look into for PyObjC as well, but for now manual building 
will do.

Ronald


> 
> -CHB
> 
> 
> 
> On Tue, Dec 6, 2016 at 12:56 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:
> 
>> 
>> 
>>> 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!
> 
> What version of Xcode do you use?  And do you use a framework build of 
> Python?  The issue I saw earlier should be present on 10.11 as well when 
> using Xcode 8.1 (which includes the 10.12 SDK)
> 
> Ronald
> 
> ___
> 
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
> <mailto:Pythonmac-SIG@python.org>
> 
> https://mail.python.org/mailman/listinfo/pythonmac-sig 
> <https://mail.python.org/mailman/listinfo/pythonmac-sig>
> 
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
> <https://mail.python.org/mailman/options/Pythonmac-SIG>
> 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> 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=file-view-default
>>>>  
>>>> <https://bitbucket.org/ronaldoussoren/pyobjc/src/3e6dce3dcfa0a3a72f9a204855d83644eaf6afc0/development-support/upload-release?at=default=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 
>

Re: [Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> 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=file-view-default
 
<https://bitbucket.org/ronaldoussoren/pyobjc/src/3e6dce3dcfa0a3a72f9a204855d83644eaf6afc0/development-support/upload-release?at=default=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

Re: [Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

> 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…)

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

[Pythonmac-SIG] PyObjC 3.2 released

[Ronald Oussoren]

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

This would work in previous versions, but no longer works because the method 
name suggests that this is a method without arguments (the translation to an 
Objective-C selector contains no colons). The workaround for this is easy 
enough: use the decorator “objc.python_method” on methods that won’t be called 
from Objective-C.

This change was necessary to make it possible to use generic decorators on 
selectors. 

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

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 25 Oct 2016, at 10:36, Andrew Jaffe <a.h.ja...@gmail.com> wrote:
> 
> On 12/10/2016 21:02, Ronald Oussoren wrote:
> >
> >> On 12 Oct 2016, at 21:09, Glyph Lefkowitz <gl...@twistedmatrix.com
> >> <mailto:gl...@twistedmatrix.com>> wrote:
> >>
> >>> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe <a.h.ja...@gmail.com
> >>> <mailto:a.h.ja...@gmail.com>> wrote:
> >>>
> >>> Not me. If I understand correctly, Glyph -- who undoubtedly
> >>> understand the situation better than I do -- still thinks that
> >>> there's no actual bug here, since we shouldn't be using the framework
> >>> build this way, but I'm not sure I understand/agree...
> >>
> >> To be honest, I'm not 100% sure this is a good idea either; it's just
> >> that I know Donald Stufft has had a terrible time with Apple system
> >> python for several years, and he regards this as a positive change.
> >>  From my personal perspective, there's a good case to be made that a
> >> python in /System should just load from /System and one in /Library
> >> should load only from /Library, similar to the way --prefix works on
> >> "regular" UNIX.  But, this is what we've got :).
> >
> > I don’t mind if the /System python looks in /Library for stuff that the
> > user installed there, but I do consider it a bug that Apple installs
> > system files in /Library because that affects all installations of
> > Python 2.7.
> >
> > That’s what we get for playing nice with OSX conventions for where to
> > locate files :-(. Luckily this isn’t a problem for Python3 as Apple
> > doesn’t ship that (and I’d be surprised if they ever unless they start
> > shipping Python3 code as part of the OS).
> 
> Well, I did submit a radar, and although I'm not sure how far the NDA 
> extends, I hope I can say that, unfortunately, I got a "behaves as intended" 
> response…

That’s too bad. But I wouldn’t expect this to change anytime soon even if this 
would have been classified as a bug.

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

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC and macOS 10.12 (Sierra)

[Ronald Oussoren]

> On 12 Oct 2016, at 08:08, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> 
> 
>> On Oct 11, 2016, at 2:26 PM, Ronald Oussoren <ronaldousso...@mac.com 
>> <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> BTW. Has anyone experience with using LLDB on Sierra? I’m currently running 
>> Sierra in a VM and for some reason LLDB doesn’t appear to work, in an SSH 
>> session I cannot start programs at all and on the console a crashing bug in 
>> the interpreter exists the interpreter instead of breaking into the 
>> debugger. That’s rather annoying when you’re trying to a debug a crash on 
>> 10.12 that doesn’t happen on 10.11.
> 
> Ever since the introduction of SIP, system-level debugging tools like LLDB 
> have worked very poorly for me, even on self-built executables.  I don't see 
> a difference in its behavior on 10.11 vs. 10.12 though.  I can run it on 
> `curl` from Homebrew, but not `python`; my guess being that Python is trying 
> to dlopen() some SIP-protected thing whereas `curl` is loading only things 
> from Homebrew?
> 
> If it's a VM, then system integrity is less of a concern; have you tried just 
> blanket disabling SIP to see if that improves the situation?  I've had some 
> luck with other tools (dtrace, mostly) working in that configuration.  (I had 
> to totally disable SIP though, disabling one flag at a time didn't work.)

I haven’t had problems with SIP on 10.11. This also doesn’t seem to be a SIP 
issue, I got the same behavior after disabling SIP.

I did manage to debug on the VM’s console by explicitly running the Python 
interpreter inside the framework (Python.app/Contents/MacOS/Python) instead of 
the launcher in {sys.prefix}/bin.  This doesn’t work in an SSH session though. 
That’s a bit annoying, but is workable until I get around to installing sierra 
on my main machine.   

Ronald

P.S. I’m debugging using a Python.org <http://python.org/> install of 
python3.5, not using the /System installation of Python2.7. Using the latter is 
asking for problems when working on a package that Apple also ships. 

> 
> -glyph
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! 
> http://sdm.link/slashdot___
> Pyobjc-dev mailing list
> pyobjc-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG