Ability to blacklist packages that are on hackage

[guest]

Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature.

So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file.

I also think cabal should tell you when it skips a dependency due to blacklisting.

[duncan]

Chucking some extra constraints in is easy. The hard part is tracking them so we can report where they came from and if they were used.

Saying that a package was not used due to blacklisting is quite hard really. I guess one could inspect the constraints at the end for each package and check if any packages were excluded only due to the specific blacklist constraint. If it was then we could check if that package would have been the preferred version vs the version actually picked.

This relies closely on the way in which the current solver works and what internal method it uses and the information it collects. That's not great because we would like to make the algorithm pluggable so that we can easily experiment with improved algorithms.

[duncan]

We seem mostly to have given up the pluggable solver interface. It now is explicitly given a set of constraints. The obvious thing to do is to attach reasons to each of the input constraints. Blacklisting could be one such thing. Avoiding broken packages similarly. See also #470.

[kosmikus]

In the modular solver, constraints have reasons already. This is related to #925.

[kosmikus]

The following works now:

• Constraints and preferences can be added to the global config file.
• Each constraint: or preference: line can specify only a single constraint, but several such lines can occur.
• Config file constraints will be handled like command-line constraints by the solver.

This can be used to specify a personal blacklist.

However, the following remains to be done:

• Make it easier to work with several config files. Currently, we can reset the config file, but not use a stack of config files. cabal-dev allows the latter.
• Distinguish config file constraints from command-line constraints in error messages.
• Allow a single config file line to contain a list of constraints.