haskell
Advertise `base<0` when a package version is deprecated
Deprecation is a subtle mechanism. In particular, deprecated versions can still be picked by the solver --- to most people's surprise. It has been brought up many times (e.g. https://github.com/haskell/hackage-server/issues/1345). A more effective way to make sure that a version isn't picked is to revise it's base bound to <0, and we should advertise it more. E.g. in the UI when a user deprecates a version, we could show an instructive message about base<0.
The above-mentioned issue has more ideas such as changing the semantics of deprecation (e.g. to be closer to that of "don't ever pick the version", just like base<0) or adding a more direct way to achieve the same by introducing a new feature in the Cabal spec. Both of these seem heavy-weight, and we are likely stuck in a local minimum for now. Adding more visibility to the base<0 trick may improve our life mid-run.
is to revise it's base bound to <0
Any unsatisfiable constraint will do. base package with <0 is just used for convenience (as virtually all packages depend on base).
Isn't this the purpose of
buildable: False?
buildable: False means that that specific component shouldn't be built, so I think that it would have the same effect if it were added to all library and executable components in the package.
o I think that it would have the same effect
No, it won't. cabal-installs solver does not backtrack on buildable: False.
No, it won't.
cabal-installs solver does not backtrack onbuildable: False.
I think that it should at least work when buildable: False is at the top level after https://github.com/haskell/cabal/pull/5337.
I think that it should at least work when
Then it's inconsistent, and thus confusing behavior.
If I have a test component with buildable: False, then cabal build --enable-tests omits that component, however if I change buildable: False to build-depends: <0 I get solver failure.
buildable: False and build-depends: base<0 are not the same. I understand what the latter does. The former does "something" very vaguely if at all specified.
EDIT: I'm afraid that inconsistency there causes problems with (public) sublibraries. My quick testing suggests that sublibraries are omitted the same way as test-suites if there's buildable: False.