chore: Flexible python version

[jsteinich]

Related issue

Fixes #282

Description

Earlier this year pipenv added supported for ranged python version requirements. There was initially a bug which prevented us from using it, but that has been fixed for months now. We can now just encode the minimum required version.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[sakul-learning]

Reviewed bbdfff9f7. Verdict: approve — no blockers.

Verification of the fix mechanism:

The Python scaffold at packages/@cdktn/cli-core/templates/python/Pipfile is written out by cdktn init --template python and handed straight to pipenv install by the template's post-hook (.hooks.sscaff.js), so the exact python_version = "3.11" pin was what made init abort on machines without 3.11. With the new value (python_version = ">=3.9") in a scratch project, pipenv install (2026.8.0) exits 0, reports Found Python satisfying >=3.9: /usr/bin/python3, and creates the virtualenv from the highest interpreter available — 3.12.3 here, despite 3.11.15 also being installed — instead of demanding the pinned version. The specifier is carried into the lock verbatim: _meta.requires.python_version reads ">=3.9".

One behavioural floor worth noting: ranged python_version needs pipenv ≥ 2026.6.0 (added in 2026.4.0, broken in 2026.4.x–2026.5.x). pipenv 2026.2.0 fails the install with Python version range specifier '>=3.9' is not supported, so users on an older pipenv get a different init failure. Not a blocker — the message is self-explanatory and current pipenv carries the fix — but a minimum-version note in the template help, or a version probe next to the existing which pipenv check in .hooks.sscaff.js, would surface it earlier.

Two minors, non-blocking: examples/python/google-cloud-function/Pipfile and examples/python/upcloud-server/Pipfile still use python_version = "3" (uneven with the rest), and the committed Pipfile.lock files still record 3.11 — that staleness predates this change, and CI's reinstall script deletes the lock before installing, so no action needed here.

[so0k]

just double check on left behind examples?