Closed RyanGlScott closed 1 month ago
@RyanGlScott you can configure which dependencies are constraint with installed:
. E.g. to disable it all together installed: -all
, or selectivelyinstalled: +all -Cabal
.
The https://github.com/haskell/cabal/issues/9917#issuecomment-2134882778 is however the true issue, and I'm not keen into working around cabal-install
release management troubles.
EDIT: The purpose of the check is to constraint that the package is built against GHC-bundled dependencies. This includes ./Setup
and also build-tool-depends
dependencies. C.f. nixpkgs and Stackage setups, these cannot use multiple versions of same package (AFAIK, maybe the situation has improved).
The flip-side is that there might be restrictive setup-depends
, which is not caught if any.
is not used. E.g. https://github.com/haskell/entropy/blob/f33d65001e96eb947879eb886840546787d556f3/entropy.cabal#L34
Thanks, @phadej. I can confirm that adding installed: +all -Cabal -Cabal-syntax
to my cabal.haskell-ci
file suffices to work around the issue described in https://github.com/haskell/cabal/issues/9917#issuecomment-2134882778.
After #727,
haskell-ci
usesany
in all generatedinstalled
constraints. While I agree with this change in principle, in practice it preventscabal
from picking a build plan for one of my projects that uses a customSetup.hs
script. See https://github.com/haskell/cabal/issues/9917#issuecomment-2134882778.Unfortunately, I am not aware of a workaround for this problem other than to remove the
any
constraint altogether. Would you agree to adding ahaskell-ci
configuration option that allows toggling the use ofany
in the generated constraints? (Perhaps it could be called--installed-any
to mirror the existing--installed
flag.) That way, I could work around this problem without needing to resort to patching the generated YAML file manually.