Fixes #1621: don't force a Chocolatey Python install when Python already exists

[vinayK34]

Fixes #1621

Problem

choco install httpie fails on any Windows machine that already has Python installed from another source:

Installing 64-bit python313...
ERROR: Running [...python-3.13.2-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 TargetDir="C:\Python313"] was not successful. Exit code was '1601'.
Failed to install python3 because a previous dependency failed.
Failed to install httpie because a previous dependency failed.

The reporter's workaround was to uninstall their own Python first — clearly not acceptable.

Root cause

docs/packaging/windows-chocolatey/httpie.nuspec declared a hard dependency:

<dependencies>
  <dependency id="python3" version="3.7" />
</dependencies>

Chocolatey resolves this by installing its own python3/python313 package, unconditionally — it has no visibility into a python.org install, so a pre-existing Python doesn't satisfy it. The MSI then fails (1601) because a Python is already installed at/near the target, and since python3 is a dependency, its failure aborts the entire httpie install.

The dependency was never actually needed for the install to work: tools/chocolateyinstall.ps1 invokes py -m pip install httpie==..., and py (the Windows Python launcher) resolves any registered interpreter, not just Chocolatey's. So the dependency's only real effect was to break installs on machines that already had Python.

Fix

1. httpie.nuspec — drop the forced python3 dependency (with a comment explaining why, so it doesn't get re-added), and document the Python requirement in the package description instead.
2. tools/chocolateyinstall.ps1 — detect an existing interpreter and validate it:
   • tries py -3, then python, then python3;
   • probes each with sys.version_info and skips any that fails to run or is older than 3.7 (so a broken shim or an old Python on PATH doesn't win);
   • if none is usable, throws a clear, actionable message pointing at choco install python3 or python.org — instead of an opaque 1601 from a nested installer;
   • checks $LASTEXITCODE after pip and throws on failure. Previously a failing pip left the package marked as successfully installed.

Verification

Tested with PowerShell 7.4.6, running the script content pulled back from the pushed branch, against stub interpreters covering each path:

Case	Result
A: existing python3 3.13.2 (the reported case)	Installing HTTPie with Python 3.13.2 from '/tmp/stub_ok/python3' → pip invoked, exit 0. No second Python installed.
E: py -3 launcher available	Preferred over bare python3 → PY_LAUNCHER_PIP: -m pip install httpie==3.2.2 ..., exit 0
B: no Python at all	exit 1 with HTTPie needs Python 3.7 or newer, but no usable Python interpreter was found on PATH...
C: Python 3.6.9 only	rejected as too old, same actionable error
D: pip returns non-zero	pip failed to install httpie==3.2.2 (exit code 1). — previously silent
F: broken python shim + working python3 on PATH	falls through to the working one, exit 0

Also verified: the script has no PowerShell parse errors ([Parser]::ParseFile), and the modified .nuspec is valid XML with 0 declared dependencies.

Note for maintainers

.github/workflows/release-choco.yml installs from '.;https://community.chocolatey.org/api/v2/' on a windows-2019 GHA image that already ships Python, so CI exercised the "dependency happens to resolve" path and never reproduced this. The workflow needs no change; with the dependency gone it now tests the real code path users hit.