Tracked here for one place; the actual deliverable lands in purescript-lua/purescript-lua-package-sets (and possibly the fork repos).

Context: #55 migrated the pslua test project to the new Spago (spago.yaml + registry). The new Spago dropped Dhall, and the Lua package set publishes only a Dhall packages.dhall, so it can no longer be pointed at as a package set. The consumer (test/ps/spago.yaml) now hard-codes every FFI fork as an extraPackages git override with an inlined dependency list, duplicating the set's data and drifting from it.

Question to resolve: can the new Spago (>= 1.x) consume a set published by purescript-lua-package-sets, so consumers point at one URL instead of enumerating git overrides?

Investigate:

• Does workspace.packageSet.url (or a local path) accept a custom, non-registry set, and does its schema allow git + ref package entries (the way the Dhall set's repo + version do)? Or is the URL format restricted to registry name -> version maps?
• If git entries are not supported in a custom set: would the forks have to be published to the PureScript Registry to appear in a registry-format set? Are these .lua-FFI forks registry-eligible at all?
• Produce a minimal PoC: a candidate set file plus a spago.yaml that consumes it and builds a trivial module against a couple of forks.

Outcome: a decision note — (A) publish a consumable set (define the format + release mechanics) or (B) fall back to per-fork spago.yaml. This spike gates the strategy-(b) issue.