Mac: Some Python Launcher issues

[ronaldoussoren]

BPO	18611
Nosy	@ronaldoussoren, @ned-deily

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/ronaldoussoren' closed_at = None created_at = labels = ['OS-mac', 'type-bug'] title = 'Mac: Some Python Launcher issues' updated_at = user = 'https://github.com/ronaldoussoren' ``` bugs.python.org fields: ```python activity = actor = 'BreamoreBoy' assignee = 'ronaldoussoren' closed = False closed_date = None closer = None components = ['macOS'] creation = creator = 'ronaldoussoren' dependencies = [] files = [] hgrepos = [] issue_num = 18611 keywords = [] message_count = 1.0 messages = ['194041'] nosy_count = 2.0 nosy_names = ['ronaldoussoren', 'ned.deily'] pr_nums = [] priority = 'normal' resolution = None stage = 'needs patch' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue18611' versions = ['Python 3.4', 'Python 3.5'] ```

[ronaldoussoren]

There are some issues with the Python Launcher application:

• [ ] There is a useless 'Help' menu, the application does not include help (removal is trivial and doesn't affect functionality)

• [ ] The list of interpreters does not include the framework locations, only /usr/local, /usr and /sw (Fink).

  IMHO the factory default should only include the framework and system pythons.

• [ ] Python Launcher should probably sniff the script for a '#!', if only to detect if the script is python 2 or 3.

  This may need to be an option, an the algoritm needs to be specified. Probably something like:

  • No #!: use app setting

  • !/usr/bin/env ...: use '...' to determine python version, use

    app setting to find that.

    Rationale: /usr/bin/env uses $PATH to find a binary, the value of $PATH for GUI apps cannot easily be changed by users (if at all, there used to be an environment.plist file but I haven't checked if thats still used by the system). Therefore it is better to use an application setting for this.

  • !/path/to/python: use that interpreter if it exists

    (not sure yet what should happen if that interpreter does not exist)

  This has several advantages over the current behavior:

  • Can use a single Python Launcher for python2 and python3 scripts
  • Works with virtualenv/pyvenv environments (assuming that the right path is used in the #! line)

See also the PEP-397 specification for the "py" launcher on windows, but I don't propose to add such a command-line tool to Mac installations, the normal Unix conventions work just fine for command-line use.

See als bpo-5262

[iritkatriel]

cc @ned-deily

[ronaldoussoren]

Some other stuff to look into (I am using this issue as a todo-list):

• [ ] There are deprecation warnings when building the app (easy enough to fix, but need to check if the replacement works on 10.9)
• [ ] We should clean up the section about the launch in the documentation
• [ ] Check opening scripts downloaded from the internet give a warning, adding code to look at quarantine info when that doesn't happen by default. That at least alleviates some of the risk described in #49512.
• [ ] Look into dropping the NIB files, the ones in the repo cannot be opened in recent Xcode versions. Our UI is simple enough to create it entirely through code (although I haven't looked into this for documented based apps yet).
• [ ] Drop support for "Python Bytecode Document", IMHO double-clicking a .pyc file to run it is not a use-case we should try to support, especially given that bytecode files are stored in __pycache__ instead of next to scripts.
• [ ] When cleaning up the list of interpeters (item 2 in the original report) also try to use --with-framework-name and framework prefix (e.g. system-wide vs user installations) to determine the correct framework location.
• [ ] Modernize source code (int->NSInteger, Nullabillity annotations, use properties)
• [ ] Add "global" preference that says where to look for interpreters:
  • /Library/Frameworks, ~/Library/Frameworks (and their order), possibly enable adding other locations
  • Select which versions to include in search (see #! interpretation in original message)