fix: ensure pip shims are always created on install (#5)

[nikolasd]

pyenv shims produced no pip/pip3/pip3.x shims after pyenv install. Verifying the fix end-to-end on a real Windows VM turned up four independent gaps across version selection, pip installation, and shim generation that all feed into the same symptom, plus one related gap in uninstall. All are fixed here.

Why pip went missing

1. Wrong artifact chosen in the first place. Import-VersionsCache kept whichever entry for a version code appeared last in .versions.xml. For every 64-bit code, the .zip (embeddable) entry is listed after the .exe/.msi entry, so a plain pyenv install 3.11.9 silently installed the embeddable zip instead of the real installer on any 64-bit machine — Install-PythonExe/Install-PythonMsi, and therefore pip installation, were never even reached. An installer entry now always wins over a zip entry for the same code, regardless of XML order; same-type duplicates keep the previous last-wins behavior.

2. Zip installs never attempted pip at all. Install-PythonZip never called anything pip-related. Some "zip" builds (e.g. the CPython arm64 archive) ship Lib\ensurepip and a pre-seeded site-packages\pip without ever having run pip's own installer, so Scripts\pip.exe never got written. It now installs pip after a successful extract, same as the exe/msi paths below; genuinely ensurepip-less builds (true embeddable packages, PyPy/GraalPy) still just warn and skip.

3. ensurepip failures were silent. The duplicated ensurepip-invocation code in Install-PythonMsi/Install-PythonExe is now one Install-Pip helper that verifies Scripts\pip.exe actually exists afterward. ensurepip can exit non-zero, or exit 0 yet leave no pip.exe (a partially broken build) — either way rehash would then silently produce no pip shims. Now it's a loud, actionable error instead of a silent "install completed" with no pip.

4. Rehash itself dropped pip even when it was installed. Invoke-Rehash scanned the version root and the Scripts/bin subfolders with inconsistent branches — non-.exe entries under Scripts/bin only got a .lnk shortcut, never a runnable .bat/shell shim. The scan is now unified across all three locations and always emits a .bat + shell shim for every runnable file, wrapped in try/catch so one bad file can no longer abort the loop and drop pip along with it. New-ShortcutShim is removed entirely — the COM WScript.Shell call throws on non-Windows and in Constrained Language Mode, and .lnk files aren't runnable by name via PATHEXT anyway.

Related: uninstall couldn't accept what install produced

pyenv install 3.11.9 on an ARM64 machine resolves (via Get-ArchPostfix) to the 3.11.9-arm64 folder, but pyenv uninstall 3.11.9 did exact folder-name matching only and reported the version as not installed — you had to type the full 3.11.9-arm64 back. pyenv-uninstall.ps1 now resolves each argument through Resolve-VersionPrefix, the same mechanism install/global/local already use, so uninstall accepts whatever install accepted.

Tests

Regression tests for all five fixes: version-table exe/msi-over-zip precedence (both orderings, plus msi-vs-zip), Install-PythonZip invoking pip installation, the pip shim family end-to-end from the Scripts scan, non-.exe Scripts entries, rehash resilience when a single file fails, and uninstall resolving a bare version to its arch-suffixed folder.

Closes #5

Branch Tree