[FIX]: Unblock deploy blocked by PEP 668 on Python 3.12

[x15sr71]

Please prefix your pull request with one of the following: [FEATURE] [FIX] [IMPROVEMENT].

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

My familiarity with the project is as follows (check one):

• I have never used the project.
• I have used the project briefly.
• I have used the project extensively, but have not contributed previously.
• I am an active contributor to the project.

---

Summary

Adds --break-system-packages and python3 (where the script used unversioned python) to all system-wide pip install commands in the deploy, rollback, bootstrap, and legacy workflow paths. Resolves the PEP 668 failure that has been blocking the sample-platform deploy since Jun 15.

Why

Deploy run #190 failed at the dependency-install step with an externally-managed-environment error:

--- Step 3: Updating dependencies ---
error: externally-managed-environment
× This environment is externally managed
Process exited with status 1

The VM runs python3 3.12.3 and ships /usr/lib/python3.12/EXTERNALLY-MANAGED. System-wide pip install is blocked by PEP 668 unless --break-system-packages is explicit. Because set -e aborts the deploy script on the failed pip call, systemctl reload platform is never reached, so even after a successful git pull the running gunicorn process keeps serving stale code.

Runs #188 and #189 failed at the same step and are likely the same issue, but only #190's full log was inspected.

The VM does not provide an unversioned python interpreter, so the legacy workflow path and install/install.sh would fail with python: command not found if invoked:

$ sudo python -m pip install ...
sudo: python: command not found

python3 replaces python in those locations for consistency with the VM environment.

Why this affects production right now

On the VM, three signals confirm the running process is stale:

• mod_test/controllers.py mtime: Jun 15 17:22 (git pull on Jun 15 succeeded)
• mod_test/__pycache__/controllers.cpython-310.pyc mtime: Mar 12 13:06 (module never re-imported)
• gunicorn PID 890167 start time: Wed Jun 3 16:41:32 (process never restarted)

Merged fixes after Jun 3 (#1118, #1119) are on disk but not in the running process.

Files patched

File	Change	Reason
install/deploy/deploy.sh:48	Add --break-system-packages	Active deploy path; fixes run #190's failure
install/deploy/rollback.sh:87	Add --break-system-packages	Rollback path; same failure mode
install/install.sh:67,69	python → python3, add --break-system-packages	Bootstrap path; python is not installed on the VM
.github/workflows/sp-deployment-pipeline.yml:84,159	python → python3, add --break-system-packages	Legacy workflow path; patched for defense in depth

Why --break-system-packages

This is a dedicated VM running a single application. System Python is the application runtime; there's no separate system Python stack to destabilize. The flag is the standard PEP 668 workaround for this configuration.

A virtualenv migration is the cleaner long-term fix but requires coordinated changes to the systemd unit, bootstrap, and call sites — out of scope for unblocking the current deploy.

Verification after merge

After the workflow runs successfully, on the VM:

ls -la /var/www/sample-platform/mod_test/__pycache__/controllers.cpython-310.pyc
ps -o pid,lstart,cmd -p $(pgrep -f "gunicorn.*sample-platform" | head -1)

Both should show recent timestamps, indicating Python re-imported the module and the gunicorn reload took effect.

Notes

This PR is intentionally scoped to the pip-install commands hitting PEP 668 and the related python → python3 fixes in the same scripts. No application logic changes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud