From `shell` to `python` - what stops you?

shell scripts are a poor choice for evolving software:

• ❌ (unit) test code for shell scripts is near zero
• ❌ no default error detection (forget set -e and an undetected disaster bubbles through the call stack)
• ❌ cryptic "write-only" syntax (e.g. echo "${file_path##*/}" vs os.path.basename(file_path))
• ❌ subtle, error-prone pitfalls (e.g. shopt nuances)
• ❌ unpredictable local/user overrides (e.g. PATH points to unexpected binaries)
• ❌ less cross-platform than it seems even on *nixes (e.g. divergent command behaviors: macOS vs Linux)
• ❌ no stack traces on failure (which encourages noisy, excessive logging instead)
• ❌ limited native data structures (no nested ones)
• ❌ no modularity (code larger than one-page-one-file is cumbersome)
• ❌ no external libraries/packages (no enforce-able dependencies)
• ❌ when shell scripts multiply, they inter-depend for reuse (by source-ing) into an entangled mess
• ❌ being so unpredictable makes shell scripts high security risks
• ❌ slow
• ...

Do not get me wrong:

• We might be shell champions to abuse it beyond its limits to get sh*t done.
• But others may want to help too - instead, they drown in shell hell.

Why not python?

The main reason I used to resort to shell:

• The need for the extra “body movements” to provide required python, populate the venv and activate it.
• Automating this for any environment immediately adds wrappers which are likely shell scripts anyway.

How to fix all this?

One attempt is:
https://github.com/uvsmtid/protoprimer

an argless reusable one-liner to bootstrap the environment with (almost) zero pre-requisites that runs everywhere:

./prime

• takes off with a wild python version (whatever is in $PATH)
• switches it in-flight to the required python version
• hands over inside a comfy isolated venv with all dependencies pinned

How would you deal with it otherwise?