Flag to solver to not pick deprecated packages.

[phadej]

AFAIK deprecated packages are less-preferred atm, but it would be make sense to try to avoid them.

Side note: when WeightedPSQ is implemented, could the penalties be adjusted? By adding insane high cost to deprecated packages, solver would barely pick them.

Another side note: cabal-install could warn that some packages in the install plan are deprecated (say with -v)

[23Skidoo]

Should be easy to implement by just filtering the package index. Or with --constraint.

[kosmikus]

As @23Skidoo says, the question is then what the intended difference in semantics from a hard constraint is.

[grayjay]

#1792 is related.

I think this would also require a change to Hackage. It currently combines deprecated and non-preferred version ranges in the index: https://github.com/haskell/hackage-server/blob/c089539780de10297d4cde424492db87e40bcda7/Distribution/Server/Features/PreferredVersions.hs#L312. (PreferredInfo contains both types of ranges: https://github.com/haskell/hackage-server/blob/c089539780de10297d4cde424492db87e40bcda7/Distribution/Server/Features/PreferredVersions/State.hs#L30)

[kosmikus]

Yes, I think I'd like if Hackage supported multiple ways of deprecating/discouraging a package version, as well as a comment as to why this is the case. Then we could also treat these differently in cabal-install.

[phadej]

I rephrase this issue: it shouldn't be a giant task to add new reasons for solver to reject packages (we are pending: buildable stuff, visibility will be next etc.) Let's rather make it easy to add new reason, so if a user wants to avoid deprecated&non-preferred packages at all cost, that feature doesn't significantly add complexity to the solver.

---

Why add to solver, and not filter: better error reporting. i.e. why some package-versions is rejected