Installation hell

[Eryk Sun]

On 12/18/22, Jim Lewis <jimdaniellewis at gmail.com> wrote:
>
> Sometimes it's a path issue.

For whatever reason, Python installations on Windows lack versioned
executable names (except for the Microsoft Store distribution). Thus
adding multiple installations to PATH doesn't help unless "python.exe"
is manually linked or copied to versioned names, e.g. "python3.11.exe"
-> "python.exe" and "python3.exe" -> "python.exe". In this case, the
first installation in PATH is the default for running "python" and
"python3".

Using the "py.exe" launcher is the more general and preferred
solution. It allows running any registered Python installation. It's
also the installed handler for the ".py" file type, and it supports
Unix-style shebangs.

> Or exe naming confusion: python, python3, phthon311, etc.

I don't understand what's supposedly confusing here. Here are some
commands to help discover what "py" or "python" commands and
installations are available.

* CMD: where py*.exe
* PowerShell: get-command py*.exe
* Python launcher: py --list-paths

> Or library compatibility issues - took an hour to find out that
> pygame does not work with the current version of python.

It should be a trivial task to discover that wheel packages for pygame
aren't currently available for Python 3.11. It is not unreasonable to
expect Python developers to familiarize themselves with pip and PyPI.

If you search a bit deeper, you'll find a site with unofficial Windows
builds of many packages, including pygame for Python 3.11:

https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame

Otherwise, while building some packages from source can be quite
involved and difficult, I'd expect anyone with a degree in computer
science to be able to build pygame if necessary. They even provide a
simple guide:

https://www.pygame.org/wiki/CompileWindows

> Then the kludgy PIP app and using a DOS box under Windows with
> command prompts which is ridiculous.

How is pip "kludgy" (i.e. sloppy, hasty, shoddy, or inelegant)? How is
using a command-line interface "ridiculous"? Many programmers and
system administrators actually prefer using command-line interfaces
and text user interfaces (TUI) for many if not most development and
administration tasks. It's a matter of opinion.

---

Nerdy operating system discussion...

> using a DOS box under Windows

The term "DOS box" refers to a virtual machine running 16-bit MS-DOS
in virtual 8086 (v86) mode under Windows 3.1 or Windows 9x, with the
MS-DOS keyboard and display drivers hooked to redirect I/O to a
desktop window. There is no "DOS box" in Windows NT systems. Windows
client systems switched to NT starting with Windows XP. Thus the term
"DOS box" is about two decades out of date.

Also, "DOS" is not synonymous with a command-line interface shell
(e.g. the 16-bit MS-DOS shell, "COMMAND.COM"). A "Disk Operating
System" is one that supports disk drives and filesystems, which
includes most operating systems from the late 1960s onward (e.g.
DOS/360 from 1966). There were several DOS systems for personal
computers in the 1980s, such as Apple ProDOS, Atari DOS, Tandy TRSDOS,
Commodore DOS, and Microsoft MS-DOS. A DOS system can use a graphical
shell, such as running Windows 1.0 (1985) on MS-DOS.

The "python.exe" executable is a Windows application that's flagged to
require a console session. If it doesn't inherit a console session,
then the system allocates one automatically. However, any Windows
application can allocate, attach to, and detach from a console session
via AllocConsole(), AttachConsole(), and FreeConsole().

Prior to Windows 7, each console session in the current NT session is
hosted on threads in the subsystem process for Windows, "csrss.exe".
Starting with Windows 7, console sessions are hosted by instances of
"conhost.exe". The console host also implements a builtin terminal
window for command-line interface (CLI) and text user interface (TUI)
applications. (A console session can be allocated without a terminal
window if a console application is spawned with the creation flag
CREATE_NO_WINDOW.)

Prior to Windows 10, the connection between a console session and its
terminal is hardwired in the console host. This makes it difficult to
implement an alternate terminal, though some alternate terminals have
managed to do so in creative ways (e.g. ConEmu). Starting with Windows
10, alternate terminals can use an open source implementation of the
console host, named "openconsole.exe". The most important example is
Microsoft's "Windows Terminal". Starting with Windows 11, an alternate
terminal can also register as the default terminal for console
applications. For example, if Windows Terminal is set as the default
terminal, then running "python.exe" from Explorer opens a new tab in
Terminal.