Re-install Python runtime for v 3.4.4 update?!

[Seamus de Mora]

The changelog for v 3.4.4 says, "You'll be asked to re-install the Python runtime."

This was a surprise! A few questions:

1. How is this done... where does the Python runtime come from for macOS Catalina - Apple, and exactly how is it re-installed?

2. I use MacPorts, and have installed Python 3 in `/opt/local/bin/python`. The default version (2.7 ?) was not removed, as I don't know if the OS needs it or not (Apple can't be bothered to disclose these things to mere users :) Also, I have configured my system to set Python 3 as my default.

Some clarification on details would be much appreciated.

[George Nachman]

We can’t use the system Python for various reasons, the most important of which are that:

1. It is often broken or weird or messed with or out of date
2. Modifying it breaks things

I build, sign, and provide a pre-build Python binary with pre-installed packages (iterm2, websockets, and pyobjc). Include pre-installed packages means that you don’t need to have Xcode installed in order to use this, which would be an 11 gigabyte download.

Installation happens while iTerm2 is running. When you try to use any feature that requires the runtime (such as creating or launching a Python API script) we check whether an acceptable version of the runtime is available.

You can have multiple versions installed concurrently. This provides backward compatibility for existing scripts.

If none is installed, you’ll be prompted to download it. It gets unzipped and placed in ~/Library/Application Support/iTerm2/iterm2env-*

While only one copy of the files exists, a number of hard links are created based on:

• Version number of the runtime
• Major Python version
• Major+minor Python version

Hard links are used for resiliency. If you upgrade from version 72 to version 73 and version 73 no longer has Python 3.7.9, you still have a working version of 3.7.9 for any scripts that depend on it.

If you create a new python API script that uses the “full environment” another set of hard links is created just for that script. This ensures it keeps working in the future no matter what happens to the systemwide runtime and that changes (such as installing a new module) will not affect any of the systemwide runtime installs. The down-side of this, besides being rather slow to create, is that full-environment scripts must be upgraded one by one when their version of the Python API ages out.

Typically a Python API will be aged out when either:

1. There is a catastrophic bug, or
2. The protocol changes in a non-backward compatible way.

It has been aged out twice so far:

1. When switching from TCP to Unix-domain sockets. This was an important security improvement.
2. In 3.4.4 because pip3 was broken when it was installed by an older app version by failing to create a symlink to ~/Library/Application Support that had no spaces. Pip3 is just broken when it comes to spaces in paths, which I did not realize until it was too late.

More details on the threat model and approach to security are here: https://gitlab.com/gnachman/iterm2/-/wikis/iTerm2-Version-3.3-Security-Updates

I hope this answers the questions, but please let me know if not. This is a rather quirky system, but I’d be failing the internet if I didn’t contribute to https://xkcd.com/1987/.

--
You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/c32bff0b-314b-4c5b-9e09-5c371eb836e0n%40googlegroups.com.