fix: reuse existing pixi if version matches on re-download

[ericdill]

Summary

When this action runs more than once in the same job with the same pixi-version, the second invocation fails with:

Error: Destination file path /home/runner/.pixi/bin/pixi already exists

determinePixiInstallation (src/options.ts) takes the "download anyway" branch whenever pixi-version or pixi-url is set — any preinstalled pixi is ignored. @actions/tool-cache's downloadTool then errors on the existing destination file.

This affects any workflow where a job composes two actions that each call setup-pixi — a common pattern when independent composite actions bring their own pixi manifests. The existing workarounds (don't set pixi-version on the second call, or give each call a distinct pixi-bin-path) are opaque — you have to find #107 to discover them, and they couple the consumer's workflow to knowledge about siblings.

Change

Before downloading, check whether the destination binary already exists:

• If it does and --version matches the requested version, skip the download.
• Otherwise, remove the stale binary so the download can proceed.
• The latest case always replaces (we can't know whether it matches without a network call and there's no real cost to re-downloading).

This preserves existing behavior (including pixi-bin-path overrides and the "ignore preinstalled pixi" branch when versions differ), just makes the happy-path idempotent.

Context

Closes #107 — the original suggestion in that issue was "check if the existing pixi version is the same as in the user input; only fail if the existing version does not match." That's what this implements.

Test plan

• CI passes (existing test matrix)
• Manual: run the action twice in one job with the same pixi-version — second invocation logs Pixi <version> already installed at ..., skipping download and succeeds.
• Manual: run twice with different pixi-version values — second invocation logs Replacing existing pixi ... and re-downloads.

Happy to add an integration test in test/ if you'd like — wasn't sure which directory best matches this scenario.

[pavelzw]

please add a unit test for your desired behavior. also, what should happen when specifying pixi-url and running twice?

[ericdill]

what should happen when specifying pixi-url and running twice?

Fair question. I gave it a decent think but didn't come up with any "clearly correct" solution. I don't have a clean answer for the pixi-url-without-pixi-version case. The core problem is that on a second invocation we can detect "a binary already exists here" but we can't detect "the URL changed since last time" without storing extra state. So any fix either silently reuses the wrong binary or always re-downloads, and neither is clearly right.

I'll close this PR since there's too much ambiguity around user intent to know what exactly to do. For my use - having it error when the file exists is unexpected. For another user - having it not error when they expected it to is just as surprising.