I can’t figure out how to use Python Launcher on Catalina. Or it is broken. Anyway: It does absolutely nothing. When I double click a scriopt file, I se very shortly the preferences window of Launcher, and this is all. The script is not executed. I made a very simple script which writes a small text file. The script works flawlessly, when I call it in the terminal, but the Launcher seems not even to open it.

Is this a bug with Catalina, or what is to be done?

Thanks for the report. At first glance, it does look like it's broken on macOS 10.15. I'll look into it.

Thank you! That’s an Information which Looks bad but has good parts. At least it may be not my fault ;)

Best regards

Werner Hintze

Am 2. Mai 2020, 19:10 +0200 schrieb Ned Deily <report@bugs.python.org>:
>
> Ned Deily <nad@python.org> added the comment:
>
> Thanks for the report. At first glance, it does look like it's broken on macOS 10.15. I'll look into it.
>
> ----------
> assignee: -> ned.deily
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue40477>
> _______________________________________

I tried to report this concern under Documentation, but got shot down as duplicate.

I have the same results. I tried to make Launcher the default "Open With" application for a script, also tried dragging (and Option dragging) the script to the Launcher, neither worked. 

I have received several results:
1. Nothing happens
2. Preference window opens
3. Launcher window with a run button opens; the run button does nothing.

An update on this: it turns out there are two different problems with the launcher app as a result of security changes introduced in macOS 10.15 Catalina.

The first is that the launcher did not execute files launched with it (for example, by double-clicking on the source file or by dragging the file to the launcher icon).  The launcher launches but no Terminal window opens.  That problem has been fixed in the just released python.org macOS installer for 3.8.3 and will be fixed in the next releases of 3.7.x and 3.9.x (pre-release).

The second problem is that the launcher app is not able to launch Terminal.app to run the script if Terminal.app was not already running. Unfortunately, I was not able to provide a fix for that problem in time for 3.8.3. However, there is a relatively easy workaround until that fix is available. Before using the launcher app, just ensure that Terminal.app is already launched; the launcher will then be able to run any number of scripts in new terminal windows as expected.  One easy standard way to launch Terminal.app is to invoke Spotlight by clicking on the "magnifying glass" icon near the upper right end of the macOS menu bar and then typing the letters "terminal" followed by the Return key in the resulting search window.  When a script is done running, just close the terminal window but don't quit Terminal.app if you want to keep using the launcher.

I appreciate the update.
As an aside, I keep the terminal in the dock.

Well heck.
I just tried it, and got an error.  The error does not occur when I run the script directly from the Terminal, nor when I run it via IDLE (double click)

Last login: Thu May 14 07:57:11 on ttys000
But what do I know? % cd '/Volumes/BigHDD/Ortho4XP-master/' && '/usr/bin/pythonw'  '/Volumes/BigHDD/Ortho4XP-master/Ortho4XP_v130.py'  && echo Exit status: $? && exit 1
Traceback (most recent call last):
  File "/Volumes/BigHDD/Ortho4XP-master/Ortho4XP_v130.py", line 9, in <module>
    import O4_Imagery_Utils as IMG
  File "./src/O4_Imagery_Utils.py", line 597
SyntaxError: Non-ASCII character '\xc2' in file ./src/O4_Imagery_Utils.py on line 597, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
But what do I know? %

Glenn, you will need to change the Interpreter setting in the Launcher Preferences panel.  In the box that says "/usr/bin/pythonw", type "/usr/local/bin/python3"; that setting will then be remembered on subsequent launches.

Thank you Ned.

So close now.  After your final fix, if I understood you correctly, we will no longer have to open Terminal? 

And, excuse my vast knowledge gap, but will it ever be possible to not have the terminal run in the future?

It is working now. However, I end up with two terminal windows open.
One is the one that I opened and the second appears to have been opened by the Launcher??

Is there no way to edit a previous comment?
Anyway, I can get it to work as described, but the Launcher Preferences window also opens when I run a script.  Did I miss a setting?

> After your final fix, if I understood you correctly, we will no longer have to open Terminal?

That's correct. That's the way the Launcher works on previous version on macOS.

> will it ever be possible to not have the terminal run in the future?

That's the way the Launcher works. It's a very simple-minded application.  Essentially all it does for you is to provide an easy way from the Finder to run a Python script in a terminal window, i.e. by double-clicking or by drag-and-drop. Like on other Unix-based systems, Python on macOS is typically used as a command line program that runs under a Unix shell in a terminal window of some sort.  Python itself does not provide a macOS GUI application interface; that is something that IDLE does (and other third-party IDEs that support Python). The Launcher app dates back to the very earliest days of Mac OS X when Python for Classic MacOS (System 9) was ported over. The Launcher is not really used very much as far as I can tell and its age shows with some usability and even security concerns. If you are comfortable using a terminal window and a Unix shell, you may find it more convenient to just run scripts directly there rather than indirectly using the Launcher, e.g.

$ cd Documents  # or whatever Folder
$ python3.8 your_script.py

Or, to open Python in interactive mode, where you can enter statements and immediately see the results:

$ python3.8

If you prefer a full-featured dev environment, you can use IDLE.

> Is there no way to edit a previous comment?

On the current bugs.python.org, no, sorry!

> the Launcher Preferences window also opens when I run a script.  Did I miss a setting?

As far as I know, opening Preferences is a "feature" of the Launcher and can't be prevented.

I believe, I found a simple way to get what you are looking for:

Open Automator and create an app.
Select »execute Shell script«
put in the editor: python3 $1

Save this as MyPythonLauncher or what you want. Test it: Drop a Python script on the app. It should execute without opening the Terminal (at least if it is a GUI-script).

If this is not clear, write me on we.hintze@gmail.com

--
Werner Hintze • Auerstraße 1 • 10249 Berlin
Tel.: +49 30 42 73 486 • Mobil: +49 160 94 68 76 60
Am 16. Mai 2020, 06:58 +0200 schrieb Ned Deily <report@bugs.python.org>:
>
> Ned Deily <nad@python.org> added the comment:
>
> > After your final fix, if I understood you correctly, we will no longer have to open Terminal?
>
> That's correct. That's the way the Launcher works on previous version on macOS.
>
> > will it ever be possible to not have the terminal run in the future?
>
> That's the way the Launcher works. It's a very simple-minded application. Essentially all it does for you is to provide an easy way from the Finder to run a Python script in a terminal window, i.e. by double-clicking or by drag-and-drop. Like on other Unix-based systems, Python on macOS is typically used as a command line program that runs under a Unix shell in a terminal window of some sort. Python itself does not provide a macOS GUI application interface; that is something that IDLE does (and other third-party IDEs that support Python). The Launcher app dates back to the very earliest days of Mac OS X when Python for Classic MacOS (System 9) was ported over. The Launcher is not really used very much as far as I can tell and its age shows with some usability and even security concerns. If you are comfortable using a terminal window and a Unix shell, you may find it more convenient to just run scripts directly there rather than indirectly using the Launcher, e.g.
>
> $ cd Documents # or whatever Folder
> $ python3.8 your_script.py
>
> Or, to open Python in interactive mode, where you can enter statements and immediately see the results:
>
> $ python3.8
>
> If you prefer a full-featured dev environment, you can use IDLE.
>
> > Is there no way to edit a previous comment?
>
> On the current bugs.python.org, no, sorry!
>
> > the Launcher Preferences window also opens when I run a script. Did I miss a setting?
>
> As far as I know, opening Preferences is a "feature" of the Launcher and can't be prevented.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue40477>
> _______________________________________

From comments in duplicate Issue46043:
"There is definitely something odd going on here. I am seeing different behaviors across different systems: I have at least one macOS 12.0.1 system where the Launcher app seems to work OK with the current 3.10.1 (as long as the Terminal.app is already running) but then on some other 12.0.1 systems and on an 11.6.1 system it fails as you describe it. This is also across a mixture of Intel and Apple Silicon systems and VMs so no obvious correlation there. Launching via IDLE does seem to work properly on the systems I've tested so perhaps that might be a temporary workaround as well as just manually running the script in a Terminal.app window. I am going to close this issue as a duplicate of Issue40477 and am bumping the priority with the aim to have a fix prior to the next round of releases in early January."

FWIW, I'm experimenting with using Scripting Bridge instead of raw Apple Events in Python Laucher.  Mostly to check if that fixes the issue because I can run scripts in Terminal using Scripting Bridge from a Python script using PyObjC.

Scripting Bridge would also result in slightly easier to read code. 


On my machine (M1 Mac Book running macOS 12.0.1) Python Launcher cannot start scripts (as described in this issue). Same when I strip code signatures (and ad-hoc sign without using the hardened runtime)

It looks like this is related to code signing and entitlements, in particular:

* On my system Terminal.app is in the "Automation" list in the Security & Privacy control panel, and none of the installed Python Launchers are
* The script let below works (assuming PyObjC is installed):
```
import ScriptingBridge

command = """cd '' && '/Library/Frameworks/Python.framework/Versions/3.10/bin/python3'  '/Users/ronald/issuequery.py'  && echo Exit status: $? && exit 1"""

app = ScriptingBridge.SBApplication.applicationWithBundleIdentifier_("com.apple.Terminal")

app.activate()
res = app.doScript_in_(command, None)
print(res)
```

* Python Launcher does not work when launched normally
* Python Launcher *does* work when I run "/Applcations/Python 3.X/Python Launcher/Contents/MacOS/Python Launcher" in Terminal.app and try to open a python file using Python Launcher
  - I've tried this with 3 variants of Python Launcher: 3.9.7 from python.org installer, no modifications; 3.10.1 from python.org installer, stripped signature and resigned ad-hoc; 3.11 installed from source with ScriptingBridge.

As mentioned before I've experimented with ScriptingBridge in Python Launcher, replacing "doscript.m" by the code below:
```
#import <Cocoa/Cocoa.h>
#import <ScriptingBridge/ScriptingBridge.h>
#import "doscript.h"

extern int
doscript(const char *command)
{
    NSObject* terminalApp = [SBApplication applicationWithBundleIdentifier:@"com.apple.Terminal"];
    //[terminalApp activate];
    NSObject* res = [terminalApp doScript:[NSString stringWithUTF8String:command] in:nil];

    NSRunAlertPanel(@"script result", @"%@", @"ok",nil, nil, res);

    return 0;
}
```

That's equivalent to the python code I posted earlier. This is not production quality code, it compiles with a warning about "doScript:in:" that can be avoided by a different way of using ScriptingBridge. That's irrelevant for this experiment though.

When I test the call to "doScript:in:" *fails* (returns nil) when launching the app regularly, and *succeeds* when running as a terminal command (as mentioned earlier).

Pfff.... Apple's documentation is too incomplete.

In recent versions the apple events entitlement only works when the program also has an NSAppleEventsUsageDescription key in Info.plist with a string value that describes why it needs the entitlement, this information is shown to the user on first launch.

When I add this key to info.plist and resign the launcher works.

I forgot to create a screenshot of this and cannot recreate the system dialog that gets shown, probably documentement somewhere that I haven't found yet...

For now I used:

<key>NSAppleEventsUsageDescription</key>
<string>Python Launcher needs this to run scripts in a Terminal window</string>

This requires no code changes.

New changeset 549e62827262264cda30455e10e315602129da72 by Ned Deily in branch 'main':
bpo-40477: macOS Python Launcher app fixes for recent macOS releases (GH-30348)
https://github.com/python/cpython/commit/549e62827262264cda30455e10e315602129da72

New changeset b312794de0f78da15593d059f09b4071d95c0d0e by Miss Islington (bot) in branch '3.10':
bpo-40477: macOS Python Launcher app fixes for recent macOS releases (GH-30348) (GH-30349)
https://github.com/python/cpython/commit/b312794de0f78da15593d059f09b4071d95c0d0e

New changeset 50da397be4f71e5c12759281446b06ce14b6a5c4 by Miss Islington (bot) in branch '3.9':
bpo-40477: macOS Python Launcher app fixes for recent macOS releases (GH-30348)
https://github.com/python/cpython/commit/50da397be4f71e5c12759281446b06ce14b6a5c4

Thanks, Ronald, for tracking down the NSAppleEventsUsageDescription requirement!

The PR here solves two problems encountered by users of the macOS Python Launcher app on recent macOS releases (10.14+):

1. The launcher app was no longer able to launch the macOS Terminal.app to run a script.

2. Even if Terminal.app was already launched, the launcher app was unable to send an Apple Event to Terminal.app to open and run Python with the desired .py file.

The solution to item 1 was to no longer specify an absolute path to Terminal.app but rather let LaunchServices figure out the path.

Item 2 was fixed by adding the NSAppleEventsUsageDescription key to the launcher app's property list. The first time the launcher runs, macOS displays a message to the user requesting permission to use Apple events; if granted by the user, the launcher will now be able to send open events to Terminal.app and all is well.

Tested on the most recent releases of macOS 12, 11, 10.16, 10.15, 10.14, and 10.9 and on both Intel and Apple Silicon Macs.

Merged for release in 3.9.10, 3.10.2, and 3.11.0a4.