[Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
From: [EMAIL PROTECTED] Subject:Re: Pythonmac-SIG Digest, Vol 20, Issue 11 Date: December 10, 2004 1:08:54 CST To: [EMAIL PROTECTED] Ran into some troubles with the below. Comments interspersed. From: Robert Valsjö <[EMAIL PROTECTED]> Date: December 8, 2004 3:06:50 CST To: [EMAIL PROTECTED] Cc: Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 How to upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 >make >make frameworkinstall make frameworkinstall pbxcp: error: open(): ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: Permission denied ...failed PBXCp ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 Fine: I did sudo make frameworkinstall, which executes without error. >make frameworkinstallextras Same privileges complaint; same solution. Change you PATH: >emacs ~/.bashrc Add: PATH=/usr/local/bin:$PATH export PATH OK. Then I do: python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> This seems to work for me. Please let me know if something is missing. Many thanks, but something is missing. Guyren G Howe ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
From: Bob Ippolito <[EMAIL PROTECTED]> Date: December 10, 2004 1:29:53 CST To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 >make >make frameworkinstall make frameworkinstall pbxcp: error: open(): ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: Permission denied ...failed PBXCp ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 Fine: I did sudo make frameworkinstall, which executes without error. >make frameworkinstallextras Same privileges complaint; same solution. Everything in the /Applications folder should be writable by anyone in the admin group, so your configuration is to blame here, not the instructions. Some package you installed probably had bad permissions... This should work for most systems. If you open up Disk Utility, there is a button that will repair permissions on a volume. With correct permissions, these steps should've succeeded. Given this error, you should probably do it. I know this is somewhat off-topic, but I ran repair permissions using Disk Utility, and then manually went in and did chmod on both Contents and Info.plist so that both owner (root) and group (wheel) could rwx and rw the folder and file, respectively. I still get the permission error shown above. Weird, huh? Change you PATH: >emacs ~/.bashrc Add: PATH=/usr/local/bin:$PATH export PATH OK. Then I do: python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> You also need to set the PATH from the shell prompt, or start a new terminal window. Editing .bashrc doesn't do anything to a currently running bash process. Works now, but only after having run the two latter makes as root. I hope that won't cause problems. Thanks for your help. Guyren G Howe ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Moving to python3.12 on M3 Max
Hmm, I’m not really sure what could cause this. One of the reasons is that I’ve really moved away from the “official” Python installer for Mac to the Homebrew-based install (see https://brew.sh/ for info on Homebrew). The big advantage of the Homebrew install is that it allows multiple version of Python to co-exist peacefully. I get the impression that I’m not the only one who has gone to homebrew-Python, but that it is more or less standard nowadays, especially among developers. So it could be that you have found an issue that the developers of Pandas are not aware of. Also, I notice that you have made 3 transitions at the same time: Intel -> Silicon, macOS 10.15 -> 10.14, Python 3.10 -> 3.12. And there are probably a whole lot of hidden changes: if you do `python3 -m pip freeze` on both machines you will get the versions of all installed packages. Comparing those might provide a lead. Especially have a look at the NumPy version: it has recently moved from 1.x to 2.0, and I know that that has caused various incompatibilities (although in general these would result in crashes, not in incorrect results). My suggestion would be to try to do only one of these transitions, for example installing Python 3.12 on your Intel Mac and comparing that to 3.10 on your Intel Mac. And if you do decide to give brew a try you can easily install Python 3.10 on your new M3 Mac and see how that goes. Oh yes, a final suggestion: the current “best practice” for managing all the Python packages that you need for a certain application is to *not* install all the needed packages into your overall system-wide Python installation. In stead, create a virtual environment and install the packages in there. There’s lots of documentation, but you can start with https://docs.python.org/3/tutorial/venv.html . The advantage of using a venv is that you can easily experiment with different versions of packages by simply creating a second venv and installing (for example) “numpy<2.0” in there. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman > On 8 Sep 2024, at 18:12, Brian Richardson via Pythonmac-SIG > wrote: > > Issue transitioning from - Macos 10.15.7 on Intel iCore i7, python 3.10 --- > to Apple M3 Max, OS 14.6, python 3.12.3: > > issued package installs to correct import errors. > > python program executes without throwing any errors/ warnings, but delivers > different results. It is a pandas > dataframe data manipulation program with read/write from/to excel using > pd.read_excel and pd.ExcelWriter. > > execution is from the Terminal command line. > PATH has > /usr/local/bin:/Library/Frameworks/Python.framework/Versions/3.12/bin up > front, input data is the same, output is not the same. > /usr/local/bin has symlinks to the Frameworks 3.12 dirs … > > What am I missing? > > Ideas appreciated. > > Thanks > ___ > Pythonmac-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG _______ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Do we want to keep pythonmac-sig?
Folks, I just got a mail from the Python mailman server admin that they will shortly be upgrading the mailman server, and the question is whether to keep the Pythonmac-SIG mailing list alive or archive it. Personally I don’t mind archiving it, we’ve had about 2-4 messages per year over the last years. But on the other hand, it isn’t a lot of work to maintain (at least not for me), I basically have to throw away the spam once a week or so. What do people think? -- 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] PyobjC using pdb on yosemite
I am setting up a 10.10 system and the current annoyance is that when pdb.set_trace() stepping through a pyobjc/py2app app everything printed, event the (pdb) prompt is piped through NSLog and hard to use. The Python version is 2.7.10 and compiled with X86_64 and MIN_DEPLOYMENT_TARGET=10.6 Perhaps someone knows a remedy. ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Problem with pip
> On 18.01.2018, at 14:58, Joni Orponen wrote: > > The offical CPython distributions seem to be compiled on 10.6 for > compatibility reasons. It is easier to compile CPython forwards-compatible > than to manually patch pyconfig.h after configure to exclude the syscalls not > available on your older target platforms. With the following config line you compile a backwards compatible Python (here 64-bit only since I don't like fiddling around with hard to compile fat-libs). # for 2.7 env MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS="-arch x86_64 " LDFLAGS="-arch x86_64 " ./configure --enable-framework --enable-ipv6 --enable-toolbox-glue and it yields a Python that can be py2apped and run on 10.6 as long as you don't use newer Frameworks or libs that need OSX > 1.6 -karsten _______ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Towards PyObjC 5.0
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: py2app 0.15
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 - [email protected] 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
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 <http://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 - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG _______ Pythonmac-SIG maillist - [email protected] 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
[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 - [email protected] 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
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 5.0b1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 5.0
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] [ANN] PyObjC 5.0
> On 21 Sep 2018, at 05:59, Glyph wrote: > > On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG > mailto:[email protected]>> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] [ANN] PyObjC 5.0
> On 21 Sep 2018, at 23:24, Glyph wrote: > > > >> On Sep 21, 2018, at 4:50 AM, Ronald Oussoren > <mailto:[email protected]>> wrote: >> >> >> >>> On 21 Sep 2018, at 05:59, Glyph >> <mailto:[email protected]>> wrote: >>> >>> On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG >>> mailto:[email protected]>> 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 - [email protected] 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
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] py2app 0.18
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 5.1
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 - [email protected] 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
> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [email protected] 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
> On 28 Oct 2018, at 19:47, Glyph wrote: > > > >> On Oct 28, 2018, at 11:20 AM, Glyph > <mailto:[email protected]>> wrote: >> >> >> >>> On Oct 28, 2018, at 2:27 AM, Ronald Oussoren >> <mailto:[email protected]>> 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 - [email protected] 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
> 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
>>> <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
> <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 - [email protected]
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)
> On 29 Oct 2018, at 00:56, Glyph wrote: > > > >> On Oct 28, 2018, at 2:57 PM, Glyph > <mailto:[email protected]>> 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 >> >> <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 > <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 > <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/ <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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [email protected] 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)
> 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 - [email protected] 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)
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 5.1.1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 5.1.2
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PMPrinterPrintWithProvider
Hi, These APIs are not available through PyObjC at this time. Why do you want these APIs instead of the higher level APIs in AppKit? Could you file an issue at <https://bitbucket.org/ronaldoussoren/pyobjc/issues?status=new&status=open <https://bitbucket.org/ronaldoussoren/pyobjc/issues?status=new&status=open>> to help me not forget to look into wrapping the Core Printing API? I’m slowly working my way through all APIs that aren’t deprecated, and haven’t gotten around to these APIs yet. Ronald — Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ > On 22 Jan 2019, at 12:07, Ben Byram-Wigfield via Pythonmac-SIG > wrote: > > Hello > > I want to use some of the Printing APIs, but I’m having trouble finding them. > Have things like PMPrinterPrintWithProvider, PMPrinterPrintWithFile, been > implemented in PyObjC? I can’t find them in ApplicationServices, AppKit, > Quartz or CoreFoundation modules. > > Thanks > > Ben > _______ > Pythonmac-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PMPrinterPrintWithProvider
> 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 - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] modulegraph2 2.0a1
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 <https://blog.ronaldoussoren.net/2019/02/03/modulegraph-a-python.html> Ronald — Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Pythonmac-SIG maillist - [email protected] 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
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 - [email protected] 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
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 5.3
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 6.0
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 6.0.1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Catalina issue
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 - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Catalina issue
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 - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] 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
> 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 - [email protected]
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist - [email protected]
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
So much for typing code in Mail.app…. “Retail” should be “retval”.
Ronald
—
Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> On 6 Jan 2020, at 15:27, Ronald Oussoren via Pythonmac-SIG
> wrote:
>
>
>
>> 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/ <https://blog.ronaldoussoren.net/>
>> _______
>> Pythonmac-SIG maillist - [email protected]
>> <mailto:[email protected]>
>> 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 - [email protected]
> <mailto:[email protected]>
> 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 - [email protected]
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
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:[email protected]>> wrote:
>>
>>
>>
>>> On 6 Jan 2020, at 00:51, Rand Dvorak >> <mailto:[email protected]>> 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 - [email protected]
>>> <mailto:[email protected]>
>>> 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 - [email protected]
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
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:[email protected]>> 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:[email protected]>> wrote:
>>>
>>>
>>>
>>>> On 6 Jan 2020, at 00:51, Rand Dvorak >>> <mailto:[email protected]>> 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.sta
Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server
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:[email protected]>> 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:[email protected]>> 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:[email protected]>> 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, requ
Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server
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.look
Re: [Pythonmac-SIG] PyObjC and Criollo HTTP server
> 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 - [email protected] 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
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC moved to GitHub
Hi, I’ve moved the PyObjC repository from BitBucket to GitHub. The new home is: https://github.com/ronaldoussoren/pyobjc/ <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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
gt; 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 “hack” from the Python.framework with a Unix install, the hard part is tweaking the build process (in particular the Makefile). BTW. I’d prefer to not add yet another build configuration on macOS, having both Unix and Framework installs is confusing enough. If the pythonw “hack” is considered useful for Unix installs it should be enabled unconditionally in 3.9. > > Then that could become the default OS-X build in the future, exactly when TBD. BTW. Looking further toward the future I’d love to spent time on creating a “Python.app” that replaces the current framework installers, with some effort that could remove the need to run installers at all and might even make it possible to distribute Python through the macOS App Store. > > The problem is that I *really* don't have the autoconf skills to do that! > > But I'm hoping with some prodding and show of support, someone with take it > on :-) I won’t, finding time to work on Python is hard enough and I’d rather not spent that time on fighting the build system ;-). Ronald > > -CHB > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Pythonmac-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
> 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 <https://github.com/ronaldoussoren/pyobjc/issues/239 <https://github.com/ronaldoussoren/pyobjc/issues/239>>. 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/ <https://blog.ronaldoussoren.net/> _______ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building plans .....
> On 15 Mar 2020, at 22:04, Christopher Barker wrote: > > On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren <mailto:[email protected]>> 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 - [email protected] 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
> 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 <http://bugs.python.org/>? Ronald ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 6.2.1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 6.2.2
Hi, I’ve uploaded PyObjC 6.2.2 to PyPI. The changelog for this release: #311 <https://github.com/ronaldoussoren/pyobjc/issues/311>: Build for the Metal bindings failed on macOS 10.14 #309 <https://github.com/ronaldoussoren/pyobjc/issues/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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Apple Silicon, anyone?
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] py2app 0.22
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Can't complete py2app build
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
test module “gaussapp.py”
import math
def gaussian(amp, delta, rt):
if delta == 0:
delta = 0.0003
n, point, peak, time, y = 0, [], [], rt-delta/2, 0
while n != 20:
sn = ((rt-time)/(.15*delta))**2
y = amp*math.exp(- sn)
time = time + delta/19
point = [time, y]
n = n + 1
peak.append(point)
peak[0][1] = 0.0
peak[19][1] = 0.0
return peak
if __name__ == "__main__":
amp = 50
delta = 0.002
rt = 7.0
i = 0
stuff = gaussian(amp,delta,rt)
while i != 20:
print (stuff[i])
py2app test “setup_gaussapp.py”
APP = ['gaussapp.py']
DATA_FILES = []
OPTIONS = {'argv_emulation': True, 'iconfile': 'Divine.icns'
}
setup(
app=APP,
data_files=DATA_FILES,
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)
___
Pythonmac-SIG maillist - [email protected]
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
I recommend switching to pyinstaller.
It seems well better maintained and is very straightfwd.
I myself switched after much trouble w/ py2app on Python3.
Cheers
> Am 26.09.2020 um 17:35 schrieb Terry Acree via Pythonmac-SIG
> :
>
> 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
>
> test module “gaussapp.py”
> import math
>
> def gaussian(amp, delta, rt):
> if delta == 0:
> delta = 0.0003
> n, point, peak, time, y = 0, [], [], rt-delta/2, 0
>
> while n != 20:
> sn = ((rt-time)/(.15*delta))**2
> y = amp*math.exp(- sn)
> time = time + delta/19
> point = [time, y]
> n = n + 1
> peak.append(point)
>
> peak[0][1] = 0.0
> peak[19][1] = 0.0
>
> return peak
>
> if __name__ == "__main__":
> amp = 50
> delta = 0.002
> rt = 7.0
>
> i = 0
> stuff = gaussian(amp,delta,rt)
> while i != 20:
> print (stuff[i])
>
> py2app test “setup_gaussapp.py”
>
> APP = ['gaussapp.py']
> DATA_FILES = []
> OPTIONS = {'argv_emulation': True, 'iconfile': 'Divine.icns'
> }
> setup(
> app=APP,
> data_files=DATA_FILES,
> options={'py2app': OPTIONS},
> setup_requires=['py2app'],
> )
>
>
>
>
> ___
> Pythonmac-SIG maillist - [email protected]
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist - [email protected]
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
> 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 - [email protected]
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
> 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 7.0
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 7.0.1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app questions
> 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 <http://python.org/>
installation of Python.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
>
> Cheers,
> Tim
>
> ___
> Pythonmac-SIG maillist - [email protected]
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 7.1
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] py2app 0.23
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] "pythonw" in a Unix build
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&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Pythonmac-SIG maillist - [email protected] 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
> On 15 Jan 2021, at 06:24, Christopher Barker wrote: > > On Thu, Jan 14, 2021 at 3:14 PM Jack Jansen <mailto:[email protected]>> 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:[email protected]>> 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&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> [email protected] >> <mailto:[email protected]>___ >> Pythonmac-SIG maillist - [email protected] >> <mailto:[email protected]> >> 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> > > -- > Jack Jansen, mailto:[email protected]>>, > http://www.cwi.nl/~jack <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 - [email protected] > <mailto:[email protected]> > 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 (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > _______ > Pythonmac-SIG maillist - [email protected] > <mailto:[email protected]> > 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> — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Pythonmac-SIG maillist - [email protected] 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
> On 18 Jan 2021, at 18:38, Christopher Barker wrote: > > On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren <mailto:[email protected]>> 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 - [email protected] 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
> 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 > > <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 > > <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 - [email protected] > 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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] py2app 0.26
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
<https://py2app.readthedocs.io/en/latest/debugging.html>.
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 - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] ANN: PyObjC 8.0
th encoding default to UTF-8 on macOS. Inheriting directly from objc.objc_object now raises TypeError instead of objc.InternalError. User code should always inherit from a Cocoa class. GH-354: Add an option to install all framework bindings, including those not relevant for the current platform. To use this: $ pip install 'pyobjc[allbindings]' Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)
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': , '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!
Thanks,
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
_______
Pythonmac-SIG maillist - [email protected]
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)
> 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&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> [email protected]
> <mailto:[email protected]>___
> Pythonmac-SIG maillist - [email protected]
> 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 - [email protected]
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)
thanks Ronald. I"m afraid starting from the common line (with open) results in the same error, and no messages to the console. Everything is in the app bundle. and I did find the template in the bundle: MapRoom.app/Contents/Resources/maproom/templates/default_project.maproom so I think what's changed is the root for the uri it's using: 'uri': 'template://default_project.maproom' Now to figure out where / how that's set. -CHB On Thu, Dec 16, 2021 at 12:05 PM Ronald Oussoren wrote: > > > On 16 Dec 2021, at 20:21, Chris Barker via Pythonmac-SIG < > [email protected]> 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&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > ___ > Pythonmac-SIG maillist - [email protected] > 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/ > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Pythonmac-SIG maillist - [email protected] 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)
OK,
I've gotten a bit farther into debugging this.
Turns out it's not about that particular error, it's probably about the
fact that modules couldn't be loaded at start up due to security checks in
the new OS.
We've signed the app but that's not fixing it :-(
Starting the app at the command line at least gets me output, and I see a
lot of errors like this:
File
"PyInstaller-3.4-py3.6.egg/PyInstaller/loader/pyiboot01_bootstrap.py", line
149, in __init__
File "ctypes/__init__.py", line 348, in __init__
OSError: dlopen(OpenGL, 10): no suitable image found. Did find:
file system relative paths not allowed in hardened programs
I am really confused as to how they could disallow relative paths -- how
else could you bundle a library?
though maybe it's a lib outside the bundle that's using relative paths ?
More digging needed, but if anyone has any ideas, I'm all ears.
Also:
- Has anyone gotten a PyInstaller App to work on OS-X 11 ?
- Even better, one that uses OpenGL?
Thanks,
-CHB
On Thu, Dec 16, 2021 at 11:21 AM Chris Barker 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!
>
> Thanks,
>
> -CHB
>
>
>
>
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> [email protected]
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
___
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Hi. I am having difficulty installing NLTK on my Mac (12.02.01). Is there anyone who can help?
I’ve been learning pylon on my Mac and and am trying to install NLTK so I can try the examples in the NLTK text. The instructions in NLTK are straightforward and I am able to get Python itself on my computer, but I cannot get “pip” to work. I would appreciate any help or sources of help. My problem seems to be getting Python to work on the data provided in the NLTK. Thank you in advance for any direction or advice you can provide. Robbie Wasserman [email protected] ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Hi. I am having difficulty installing NLTK on my Mac (12.02.01). Is there anyone who can help?
> On Mar 3, 2022, at 4:17 PM, Ned Deily wrote: > > On Mar 3, 2022, at 16:15, Ned Deily wrote: >> On Feb 27, 2022, at 15:51, Robert Wasserman via Pythonmac-SIG >> wrote: >>> >>> I’ve been learning pylon on my Mac and and am trying to install NLTK so I >>> can try the examples in the NLTK text. >>> >>> The instructions in NLTK are straightforward and I am able to get Python >>> itself on my computer, but I cannot get “pip” to work. >>> >>> I would appreciate any help or sources of help. My problem seems to be >>> getting Python to work on the data provided in the NLTK. >> >> Sorry but without more information, it is impossible to provide meaningful >> help. But the most common problem with using pip is trying to use the wrong >> version of pip. The best way to avoid that is to invoke pip using the same >> name you are using to invoke python itself. So, for example, from a Terminal >> window, if you type "python3" to start up Python, use this: >> >> python3 -m pip install ntlk > > Er, of course, that should be: > > python3 -m pip install nltk > >> If you are still having problems, please copy and paste the full sequence of >> commands that you are entering and the error messages you see. >> >> FWIW, I just tried it with the current Python 3.10.2 macOS installed from >> python.org and it seemed to work. >> >> P.S. general Python usage questions are probably more quickly solved via one >> of the general help forums out there. See https://www.python.org/about/help/. > > -- > Ned Deily > [email protected] -- [] > ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Building against OpenGL
]
## fixme: this needs a lot of work!
##it's really compiler dependent, not machine dependent
if sys.platform == 'darwin':
print("adding no CPU flags for mac")
## according to:
## http://www.christian-seiler.de/projekte/fpmath/
## nothing special is required on OS-X !
##
## """
## the precision is always determined by the largest operhand type in C.
##
## Because of this, Mac OS X does not provide any C wrapper macros to
## change the internal precision setting of the x87 FPU. It is simply
## not necessary. Should this really be wanted, inline assembler would
## probably be possible, I haven't tested this, however.
## Simply use the correct datatype and the operations performed will have the
## correct semantics
## """
elif sys.platform == 'win32':
print("adding define for Windows for FPU management")
DEFINES.append(('CPU86', None))
elif 'linux' in sys.platform :# something for linux here...
print("adding CPU flags for Intel Linux")
DEFINES.append(('LINUX', None))
else:
raise RuntimeError("this system isn't supported for building yet")
pytriangle = Extension(
"libmaproom.pytriangle",
sources = [ "libmaproom/pytriangle-1.6.1/src/pytriangle.pyx",
"libmaproom/pytriangle-1.6.1/triangle/triangle.c" ],
include_dirs = [ numpy.get_include(),
"libmaproom/pytriangle-1.6.1/triangle",
],
define_macros = DEFINES,
)
# Extension module is named libmaproom.contour rather than libmaproom.py_contour
# because imports get confused with the py_contour source directory within the libmaproom
# directory (error message "dynamic module doesn't define module export function"), but
# moving the py_contour directory outside of the libmaproom directory doesn't seem to help.
py_contour = Extension(
"libmaproom.contour",
sources = [
"libmaproom/py_contour/py_contour/contour.pyx",
"libmaproom/py_contour/py_contour/conrec.cxx",
],
include_dirs = [
numpy.get_include(),
],
)
ext_modules = [bitmap, shape, tessellator, render, pytriangle, py_contour]
#ext_modules = [tessellator]
data_files = []
options = {}
package_data = {}
install_requires = [
'numpy',
'pyopengl',
'cython',
]
setup(
name="libmaproom",
version=__version__,
description="Compiled support libraries for MapRoom",
author="NOAA",
install_requires=install_requires,
setup_requires=[
'packaging',
],
data_files=data_files,
packages=['libmaproom'],
package_data=package_data,
ext_modules=ext_modules,
options=options,
zip_safe = False,
)
___
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Building against OpenGL
As usual, once you pose the question -- you find the answer.
The trick was not to try to link directly, but rather to use Apple's nifty
"Framework" concept:
extra_link_args.append("-framework OpenGL")
Posting this in case anyone else happens upon it.
-CHB
On Tue, Mar 22, 2022 at 12:47 PM Chris Barker wrote:
> I have an app that uses a C (Cython) extension that needs to link against
> the OpenGL libs (libGL and libGLU)
>
> Here's the code that used to work:
>
> gl_libraries = ["GL", "GLU"]
>
> ...
>
> gl_include_dirs.append(
> "/System/Library/Frameworks/OpenGL.framework/Headers",
> )
>
> gl_library_dirs.append("/System/Library/Frameworks/OpenGL.framework/Libraries",
> )
>
> And this resulted in this linking line that fails:
>
> clang -bundle -undefined dynamic_lookup
> -Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
> -L/Users/chris.barker/miniconda3/envs/maproom39/lib
> -Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
> -L/Users/chris.barker/miniconda3/envs/maproom39/lib
> build/temp.macosx-10.9-x86_64-3.9/libmaproom/Tessellator.o
> -L/System/Library/Frameworks/OpenGL.framework/Libraries -lGL -lGLU -o
> build/lib.macosx-10.9-x86_64-3.9/libmaproom/
> Tessellator.cpython-39-darwin.so
> ld: library not found for -lGL
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command '/usr/bin/clang' failed with exit code 1
>
> Some of this makes sense -- as System/Library/Frameworks/OpenGL.framework
> doesn't
> have Libraries and Headers anymore. However, it also doesn't have the
> headers or libraries (that I can tell) anywhere else in there.
>
> Oddly, the compiler is finding the headers somewhere -- not sure where.
>
> Google has failed me here -- but a few hints:
>
> 1) ctypes had to be updated to find the libs -- that was done, and ctypes
> seems to be working. but what it does is:
>
> In [1]: from ctypes.util import find_library
> In [2]: find_library("OpenGL")
> Out[2]: '/System/Library/Frameworks/OpenGL.framework/OpenGL'
>
> but /System/Library/Frameworks/OpenGL.framework/OpenGL doesn't exist on
> my system at all.
>
> Reading a bit -- it seems that OS-X is doing some kind of cached libs
> trickery -- but how do I tell distutils / clang how to find those libs??
>
> Enclosed is the whole setup.py in case I've missed a detail.
>
> Sometimes Apple Drives me crazy! Thanks for any hints --
>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> [email protected]
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
___
Pythonmac-SIG maillist - [email protected]
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
> 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 - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] PyObjC 9.1b1
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
<https://pyobjc.readthedocs.io/en/latest/changelog.html>.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Mastodon: @[email protected].
Blog: https://blog.ronaldoussoren.net/
___
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] [ANN] PyObjC 10.0 released
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: @[email protected]. Blog: https://blog.ronaldoussoren.net/ ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Moving to python3.12 on M3 Max
Issue transitioning from - Macos 10.15.7 on Intel iCore i7, python 3.10 --- to Apple M3 Max, OS 14.6, python 3.12.3: issued package installs to correct import errors. python program executes without throwing any errors/ warnings, but delivers different results. It is a pandas dataframe data manipulation program with read/write from/to excel using pd.read_excel and pd.ExcelWriter. execution is from the Terminal command line. PATH has /usr/local/bin:/Library/Frameworks/Python.framework/Versions/3.12/bin up front, input data is the same, output is not the same. /usr/local/bin has symlinks to the Frameworks 3.12 dirs … What am I missing? Ideas appreciated. Thanks ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Moving to python3.12 on M3 Max
> Am 16.09.2024 um 22:04 schrieb jack.jansen--- via Pythonmac-SIG > : > > The big advantage of the Homebrew install is that it allows multiple version > of Python to co-exist peacefully. I have python.org 3.8 to 3.13 installed and it works just fine (don’t ask why). You can access each version with a `python3.X` and `pip3.X` binaries. `python` and `python3` will be of the version you installed last. Georg ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Python Security Survey - Your Expertise Needed!
Hello Python Developers and Security Engineers, I’m Reem Almutairi, a Ph.D. student in Software Engineering at King Saud University. I’m conducting research to better understand the prevalence and impact of security vulnerabilities in Python, as well as the strategies developers use to mitigate these risks. If you have experience in Python and are familiar with security vulnerabilities, I’d greatly appreciate your input in this 10-minute survey. 👉 [ https://n9.cl/2ow2c [https://lh6.googleusercontent.com/2RkP1spcsyjz1WD_HnUioMUEHvWWna6Cn0HrU7U9V_HKwXbnWsXr7futHg1JDb2m_k01A8ttA8A=w1200-h630-p]<https://n9.cl/2ow2c> Identifying Key Software Security Vulnerabilities (Security Smells) in Python Applications<https://n9.cl/2ow2c> n9.cl ] Also, if you know others who might be interested, please feel free to share the survey link with them! Your insights will help shape future security practices in Python development. Thank you in advance for your time and expertise. Warm regards, Reem Almutairi Ph.D. Student, Software Engineering King Saud University ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Python[676:3763] +[NSXPCSharedListener endpointForReply:withListenerName:replyErrorCode:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Co
Dear experts, We encountered below NSXPC issue that is similar with one in https://www.mail-archive.com/[email protected]/msg12027.html, below issue happened in python3.9 with MacOS Monterey and Sonoma. [2024-10-17T01:42:00.390405+00:00] 2024-10-16 18:42:00.389 Python[676:3763] XType: Using static font registry. [2024-10-17T01:42:13.660839+00:00] 2024-10-16 18:42:13.659 Python[676:3763] +[NSXPCSharedListener endpointForReply:withListenerName:replyErrorCode:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Connection interrupted [2024-10-17T01:42:13.986531+00:00] 2024-10-16 18:42:13 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IHDR' 16 13 [2024-10-17T01:42:13.986888+00:00] 2024-10-16 18:42:13 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'sBIT' 41 4 [2024-10-17T01:42:13.987644+00:00] 2024-10-16 18:42:13 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG b'sBIT' 41 4 (unknown) [2024-10-17T01:42:13.988090+00:00] 2024-10-16 18:42:13 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'pHYs' 57 9 [2024-10-17T01:42:13.988616+00:00] 2024-10-16 18:42:13 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IDAT' 78 1189 [2024-10-17T01:42:14.003123+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IHDR' 16 13 [2024-10-17T01:42:14.003719+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'sBIT' 41 4 [2024-10-17T01:42:14.004236+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG b'sBIT' 41 4 (unknown) [2024-10-17T01:42:14.004939+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'pHYs' 57 9 [2024-10-17T01:42:14.005671+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IDAT' 78 2994 [2024-10-17T01:42:14.131532+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IHDR' 16 13 [2024-10-17T01:42:14.131582+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'sBIT' 41 4 [2024-10-17T01:42:14.131591+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG b'sBIT' 41 4 (unknown) [2024-10-17T01:42:14.131597+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'pHYs' 57 9 [2024-10-17T01:42:14.131604+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local PIL.PngImagePlugin[676] DEBUG STREAM b'IDAT' 78 374 [2024-10-17T01:42:14.146875+00:00] 2024-10-16 18:42:14 e1f776b1-60fc-4e36-97c5-dbaec20701b2.local issuebot.flows.Flow[676] ERROR Traceback (most recent call last): [2024-10-17T01:42:14.146929+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot/flows/Flow.py", line 209, in _run_plugins [2024-10-17T01:42:14.146938+00:00] plugin.execute(context) [2024-10-17T01:42:14.146946+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plugins/classifiers/astro/SMCDataAnalyticsImportClassifier.py", line 578, in execute [2024-10-17T01:42:14.146953+00:00] have_param_fails |= analyze_a_record( [2024-10-17T01:42:14.146959+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plugins/classifiers/astro/SMCDataAnalyticsImportClassifier.py", line 480, in analyze_a_record [2024-10-17T01:42:14.146966+00:00] have_param_fails = add_parametric_fail( [2024-10-17T01:42:14.146971+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plugins/classifiers/astro/SMCDataAnalyticsImportClassifier.py", line 464, in add_parametric_fail [2024-10-17T01:42:14.146977+00:00] add_attachments_to_issue( [2024-10-17T01:42:14.146983+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plugins/classifiers/astro/SMCDataAnalyticsImportClassifier.py", line 410, in add_attachments_to_issue [2024-10-17T01:42:14.146989+00:00] add_chart_to_issue(astro, context, all_found, tests, current_test, issue, [2024-10-17T01:42:14.146995+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plugins/classifiers/astro/SMCDataAnalyticsImportClassifier.py", line 369, in add_chart_to_issue [2024-10-17T01:42:14.147000+00:00] TestDataCharting.build_plots_for_results( [2024-10-17T01:42:14.147007+00:00] File "/Users/issuebot/.env/lib/python3.9/site-packages/issuebot_osd/plu
[Pythonmac-SIG] ANN: PyObjC 11.0
I'm happy to announce the 11.0 release of PyObjC, slightly delayed from the
normal major release in October.
This release has two major features:
Support for the macOS 15.2 SDK, including new bindings for the frameworks
MediaExtension and DeviceDiscoveryExtension
Experimental support for GIL-less operation in the free-threaded build of
Python 3.13
The latter feature is an important reason for the delay: Supporting GIL-less
operation required reworking parts of the internals of PyObjC, both to rely on
other locks than the GIL and to avoid CPython APIs that are known to be
problematic when the GIL isn't present ("borrowed references" for anyone
familiar with the CPython API).
Free-threaded support is experimental at this point in time and has seen only
limited testing for multi-threading. I've also focussed on getting the basics
right, and have not worked at optimizing free-threading support. Expect
improvements in future releases.
With PyObjC 11 I'm dropping support for Python 3.8, given that that's gone out
of support by the CPython team.
Finally, there's a number of bug fixes and smaller features mentioned in the
changelog at https://pyobjc.readthedocs.io/en/latest/changelog.html
Ronald
--
Twitter / micro.blog: @ronaldoussoren
Mastodon: @[email protected].
Blog: https://blog.ronaldoussoren.net/
_______
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] We are keeping pythonmac-sig.
Ok folks, There seems to be enough interest to keep the list, and it isn’t enough of a burden on me. We’ve now moved to mailman 3. Regards, Jack > On 21 May 2025, at 22:27, [email protected] wrote: > >> >> On May 16, 2025, at 6:52 PM, Matthew Dixon Cowles wrote: >> >> Jack, >> >>> I just got a mail from the Python mailman server admin that they >>> will shortly be upgrading the mailman server, and the question is >>> whether to keep the Pythonmac-SIG mailing list alive or archive it. >> >>> Personally I don’t mind archiving it, we've had about 2-4 >>> messages per year over the last years. >> >> I think that the fact that there isn't a lot of traffic should be >> taken as a sign of success. You and the other people who work on the >> releases deserve a lot of credit. >> >> For myself, I'm glad that there's a place where it's possible to get >> the attention of the platform experts because very occasionally a >> platform issue comes up. For example, a month ago we got a question >> over on the python-help list about Python for Windows on ARM and it >> was a little trouble tracking down someone who could answer it. (In >> case anyone's curious: Python for Windows on ARM isn't on Microsoft's >> store because few binary modules are compiled for it and Microsoft >> doesn't want users to be mad and/or confused when, for example, "pip >> install pandas" doesn't work for it.) >> >> That said, I don't much mind whether that place is here on this list >> or over on a section of the PSF's web board. I tend to like mailing >> lists a little more, but that's a very minor thing. > > Similarly, I'd like for there to be somewhere to go, and the list is > convenient, but as long as the archiving comes along with an official > designation of a thread on the Discourse board or something, that's all I > would need to be happy. > > -g > ___ > Pythonmac-SIG mailing list -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > https://mail.python.org/mailman3//lists/pythonmac-sig.python.org > Member address: [email protected] <mailto:[email protected]> ___ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] [ANN] PyObjC 12.0
Hi, I’ve tagged PyObjC 12.0 and uploaded it to PyPI. This release introduces support for APIs that were introduced in macOS 26.0, and removes support for Python 3.9. The website still mentions PyObjC 11 as the latest release, that will change later today. The PyObjC 12.1 release should be closer to the release of macOS 12.1. The 12.0 release was primarily delayed because I spent most of September traveling. Ronald — Twitter / micro.blog: @ronaldoussoren Mastodon: @[email protected]. Blog: https://blog.ronaldoussoren.net/ ___ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] Re: Concerns about the Python library appscript
Thanks for the positive news! I really loved OSA at the time, and I’ve used it extensively. But the last two things I wanted to automate failed utterly. Photos still has something of a dictionary, but you can do little more than control a slide show. No way to do usable searches (like “any photo taken in such-and-such an area in December”). And Mainstage has no dictionary at all (and _that_ would be an absolutely wonderful app to control). Logic Pro has a dictionary but it allows little more than closing a window. ince then I’ve sort-of given up on it. But I’ll at least try again if I want to automate something. Jack > On 22 Aug 2025, at 18:33, [email protected] wrote: > > > >> On Aug 22, 2025, at 2:54 AM, Jack Jansen via Pythonmac-SIG >> wrote: >> >> I think your out of luck: >> >> https://appscript.sourceforge.io/status.html >> > > While appscript is not seeing new features, it's more "done" than > "unmaintained". hhas seems to do new builds for new operating systems and > updates for new versions of Python. I'm using it quite successfully on python > 3.13 and Sequoia, 13 years after this message went up, and 10 years after > (allegedly) "Apple eliminated its Mac Automation department". > > I wouldn't base a major new business on it or anything but it always bugs me > to see folks scared away from this perfectly usable automation technology > with vague fearmongering about its future, 15 years into that "future" being > declared dead and gone. > >> Also, note that AppleScript itself (or actually I should probably say OSA) >> is as good as dead, unfortunately. >> >> >> Apple doesn’t actively support it anymore, and new programs don’t seem to >> get any OSA support… > > > What do you mean by "actively support it"? The "Privacy & Security -> > Automation" access control integration with the new security model is only a > few years old at this point. New applications like Shortcuts have OSA > support. 3rd party apps like Acorn and OmniFocus have good scripting > integration, and first-party stuff like Pages/Numbers/Xcode also have good > integration that are hard to access in other ways. > > For what it works for, OSA is fine. People have been saying it's dead for > like 15 years now, but it still works great and has much nicer, finer-grained > security tools than it used to. It's probably not the future of any big new > automation push. That will be Shortcuts, and, ugh, "Apple Intelligence". But > I strongly suspect that once OpenAI goes bust and Siri's ChatGPT integration > stops working, we'll still have AppleScript. > >>> On 20 Aug 2025, at 10:07, Thia Clay wrote: >>> >>> is the Python library appscript still developing? if so, how can I build >>> the wheel with GCC in Windows? >>> ___ >>> Pythonmac-SIG mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> https://mail.python.org/mailman3//lists/pythonmac-sig.python.org >>> Member address: [email protected] >> >> >> ___ >> Pythonmac-SIG mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3//lists/pythonmac-sig.python.org >> Member address: [email protected] > ___ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] Re: Concerns about the Python library appscript
[Jack donning his boring-old-fart hat] The thing is, when Apple came up with this stuff in the late 1990s, if developers had adopted it it would have made their life _so much easier_. Because really a lot of the business logic of their own app could have been expressed in OSA, leading to much cleaner separation between model/view/controller and how the business logic and the UI connect…. And COM/OLE was a far cry from OSA, but actually it was still somewhat usable, and with somewhat the same goals... But that ship has sailed (or that bridge has been burned, whatever)…. > On 25 Aug 2025, at 04:42, Greg Ewing wrote: > > On 25/08/25 7:56 am, Jack Jansen via Pythonmac-SIG wrote: >> But the last two things I wanted to automate failed utterly. Photos still >> has something of a dictionary, but you can do little more than control a >> slide show. No way to do usable searches (like “any photo taken in >> such-and-such an area in December”). And Mainstage has no dictionary at all >> (and _that_ would be an absolutely wonderful app to control). Logic Pro has >> a dictionary but it allows little more than closing a window. > > The problem with OSA is that making an app usefully scriptable requires a lot > of extra work that doesn't contribute to the app's core functionality. It's > understandable that many developers don't bother or only do a minimal job of > it, especially if the Mac platform is not their main focus. > > -- > Greg > > ___ > Pythonmac-SIG mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/pythonmac-sig.python.org > Member address: [email protected] ___ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] Re: Concerns about the Python library appscript
I think your out of luck: https://appscript.sourceforge.io/status.html Also, note that AppleScript itself (or actually I should probably say OSA) is as good as dead, unfortunately. Apple doesn’t actively support it anymore, and new programs don’t seem to get any OSA support… > On 20 Aug 2025, at 10:07, Thia Clay wrote: > > is the Python library appscript still developing? if so, how can I build the > wheel with GCC in Windows? > _______ > Pythonmac-SIG mailing list -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > https://mail.python.org/mailman3//lists/pythonmac-sig.python.org > Member address: [email protected] <mailto:[email protected]> _______ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] Re: Concerns about the Python library appscript
> On 20. Aug 2025, at 10:07, Thia Clay wrote: > > is the Python library appscript still developing? if so, how can I build the > wheel with GCC in Windows? Opposite to all rumors appscript isn't dead yet - it may have some funny code smells. Just recently I recompiled several of my apps for os15.6 with python 3.13 and they run; using appscript to control FileMaker & the Finder. BUT. appscript is strictly Macintosh only. You cannot build or run on Windows or Linux. _______ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] Re: Concerns about the Python library appscript Addendum
The current repo is on github: https://github.com/hhas/appscript ___ Pythonmac-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/pythonmac-sig.python.org Member address: [email protected]
[Pythonmac-SIG] PMPrinterPrintWithProvider
Hello I want to use some of the Printing APIs, but I’m having trouble finding them. Have things like PMPrinterPrintWithProvider, PMPrinterPrintWithFile, been implemented in PyObjC? I can’t find them in ApplicationServices, AppKit, Quartz or CoreFoundation modules. Thanks Ben ___ Pythonmac-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Catalina issue
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 - [email protected] https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] Supplying Unicode strings to pyobjc
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)
But that will only work for “ASCII” range characters. Any characters greater
than 128 gives:
ValueError: depythonifying 'char', got 'int' of wrong magnitude
It all works perfectly in python2. I presume because objc wants “const char
*filename”, rather than an actual string.
How should I be presenting these strings?
I’ve been struggling with this for years, and so stayed on python2 as long as
possible.
Thanks
Ben Byram-Wigfield
_______
Pythonmac-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
