Unfortunately, Ned's right in highlighting a potential pip integration problem here: pip DOES NOT expose a supported Python API, but pip_tkinter currently imports APIs from within the pip package.

This means that somebody doing "pip install --upgrade pip" may break a version of the GUI that is implemented this way, contradicting our promise that a post-install "pip install --upgrade pip" is a fully supported operation that won't break anything else in CPython.

That's 100% fine for a proof of concept that demonstrates the general principle of a Tkinter based package management GUI and it's integration into IDLE (and Upendra's work on that front looks excellent to me), but isn't reasonable for a version that actually lands in CPython as a supported component.

Where this work could really help move the "Stable Python API for package management" discussion forward is by providing a clear set of use cases, as well as spelling out the internal pip APIs used to implement that feature in the proof-of-concept,

The reason I believe that will be helpful is that one of the big problems in this area to date has been the lack of a clear statement of the problem that a stable Python API would be aimed at solving - "provide a stable API that meets the needs of the default package management GUI shipped with IDLE" is a far more tractable problem than "provide a stable API for pip".