fix(update): detect local-path installs instead of blaming PyPI propagation

[acmck]

Fixes #56.

Problem

With getop installed from a local checkout (pipx install /path/to/getop), getop update would run pipx upgrade, which re-resolves the recorded spec and reinstalls from disk — so the version never moves, and update printed the fallback message for a different failure mode: "1.2.0 isn't installable yet — PyPI is still propagating the release."

Fix

Instead of shelling out to pipx list --json (issue's suggestion), read the PEP 610 direct_url.json from the installed distribution: every installer (pip, pipx, uv) writes it for local-path/URL/editable installs, and PyPI installs have none — one check covers pipx, uv tool, and pip alike, including the uv-tool case the issue deferred.

When a local source is detected and an update is available:

$ getop update
Update available: 1.1.0 → 1.2.0
getop was installed from /Users/x/src/getop, not PyPI — upgrading would just reinstall from there.
Switch back to PyPI releases: pipx uninstall getop && pipx install getop

• The hint is installer-aware: pipx uninstall getop && pipx install getop (pipx's uv backend refuses --force over a foreign venv), uv tool install --force getop, or plain pip upgrade.
• update exits 1 (nothing was updated); --check reports the same and exits 0.
• --json gains a local_source key (null for PyPI installs).

Verification

• uv run pytest -q — 138 passed (5 new tests: direct_url parsing incl. absent/malformed, blocked-update exit 1 with no "propagating" text, --check exit 0, --json key, per-method hints)
• Live: uv run getop update --json in the dev checkout (an editable path install) correctly reports "local_source": "…/getop"; the released PyPI pipx install has no direct_url.json, matching the null path

🤖 Generated with Claude Code