pklrun: re-resolve PklProject when deps.json is stale (not just absent)

[naxty]

Summary

pklrun (introduced in #494) auto-runs pkl project resolve only when PklProject.deps.json is absent. It keys off file existence, not freshness — so editing a PklProject's dependencies without deleting deps.json leaves stale resolved deps in place and they are used silently.

This was an explicit, accepted scope decision for #494 (D1: resolve-only-if-missing). This issue tracks closing the staleness gap as a follow-up.

Symptom

1. Resolve a project once → PklProject.deps.json is created.
2. Edit PklProject: add / bump / remove a dependencies { ... } entry.
3. Run formae apply / eval again.
4. Old resolved deps are used. New dep appears "not found" or pinned to the wrong version. Only fix today is manually rm PklProject.deps.json.

Where

• pkg/plugin/pklrun/pklrun.go — ensureProjectResolved checks os.Stat(deps) and returns early if it exists.

Options

• Compare mtimes: re-resolve when PklProject is newer than PklProject.deps.json.
• Hash the dependencies block and store/compare alongside deps.json.
• Escape hatch: a --resolve/--force-resolve flag or FORMAE_PKL_RESOLVE=always env var.

mtime comparison is the cheapest correct default; the env/flag is a useful complement for "always re-resolve" workflows.

Out of scope

Concurrency hardening of the resolve write (parallel applies racing on deps.json) is a separate concern — tracked elsewhere.

Refs

• PR feat(pkl): auto-resolve PklProject deps via shared pklrun evaluator #494 (introduces pklrun + auto-resolve)

[naxty]

Status update

A partial fix landed in PR #494 (commit a00c578a): ensureProjectResolved now also re-resolves when the top-level PklProject is newer than PklProject.deps.json (mtime check), not just when deps.json is absent.

This is a cheap fast-path, not the complete fix. Known blind spots:

• Transitive local deps — only the top-level PklProject mtime is checked. A changed dependency PklProject (formae uses import("../../PklProject")-style local deps heavily) is not detected.
• mtime ≠ content — a no-op touch / checkout-order can trigger a spurious resolve.

Robust fix to implement here

Delegate staleness to pkl (the authority) via resolve-on-hint, retry once:

Load the project; if pkl fails with its Try running \pkl project resolve`` hint (emitted for missing and changed/transitive cases), run resolve and retry the load once.

This inherits pkl's full resolution semantics (remote constraints, checksums, transitive local graph) instead of reimplementing them. Implement inside pkg/plugin/pklrun around LoadProjectFromEvaluator; gate the retry to exactly once. Optional eval-time safety net: wrap Evaluate* too for deps errors deferred to evaluation time.

Keeping this issue open for that work; the mtime fast-path can remain as an optimization layered under it.