haskell
Implement candidate index
This provides cabal with the means to conveniently opt into accessing package release candidates, by presenting them as a secondary package index to cabal. This secondary package index would have lesser guarantees (this follows from the properties/nature of package candidates; specifically, .cabal revisions are not supported, instead package releases can be deleted, or be mutated destructively in-place). The primary and candidate index are comparable to Debian's "stable" and "testing"/"experimental" distributions respectively; package releases start in the transient candidate index, and can be promoted to the eternal/monotonic primary index if they pass basic validations.
TODO: specify design in more detail
@23Skidoo Only as an external prototype (which is intended so we can adapt/extend cabal's multi-repo support to properly handle it -- NB: the candidate index violates a few assumptions you have w/ the primary index): http://cand.hackage.haskell.org/
This URL died with the hackage matrix, unfortunately.
As this candidate index didn't get implemented within 5 years, maybe candidates could be made available in the primary index but labeled as candidates? Would that be more light weight and easier to implement? However, this would require the cabal solver to be modified with some strategy when to pick candidates, so it does not sound that elegant.
However, this would require the cabal solver to be modified with some strategy when to pick candidates,
Not only cabal solver, but all tools which read index directly.
Also primary index is append only (= has been so far), yet candidates are not permanent.
Bad idea. Please don't do it.
