Closed andreasabel closed 1 year ago
Is this working as intended?
Yes. Unconstrained build is... unconstrained. If you use allow-newer
things may go bananas. Yet, jobs with prerelease GHC are allowed to fail.
Steep learning curve...
I think a brutto allow-newer: *:Foo
is often not what I want. What I want 99% of the time is an allow-newer: latest:Foo
, which only allows newer Foo
for each latest version of any package available.
E.g. allow-newer: Cabal:base
would not apply to Cabal-3.2.1.0
which has a native base < 4.15
(and thus is likely outdated).
Alternatively, an allow-newer
which only allows to skip to the next major version (as opposed to skipping arbitrarily many major versions) would also often be more helpful than the brutto version.
Feel free to request that feature on cabal-install
issue tracker. I'd be happy to do allow-newer
for the latest (non deprecated) release only.
Note: we have to do wildcard allow-newer: *:base
as there is no way to know which of all dependencies will need the relaxed upper bounds (technically each if PVP were followed strictly).
With
head
job we get this incabal.project
:allow-newer: *:Cabal, *:Cabal-syntax, *:array, *:base, *:binary, *:bytestring, *:containers, *:deepseq, *:directory, *:exceptions, *:filepath, *:ghc, *:ghc-bignum, *:ghc-boot, *:ghc-boot-th, *:ghc-compact, *:ghc-heap, *:ghc-prim, *:ghci, *:haskeline, *:hpc, *:integer-gmp, *:libiserv, *:mtl, *:parsec, *:pretty, *:process, *:rts, *:stm, *:system-cxx-std-lib, *:template-haskell, *:terminfo, *:text, *:time, *:transformers, *:unix, *:xhtml,
Usually, its effects are moderated by matching
installed
constraints incabal.project.local
:However, in the "unconstrained build", the
cabal.project.local
is deleted while thecabal.project
remains in place. As a consequence, we can get wild build plans, e.g.Cabal-3.2.1.0
paired withCabal-syntax-3.8.1.0
Is this working as intended?
There is a setting
unconstrained-build:
forcabal.haskell-ci
which I could set to< 9.6
to prevent such false negatives. Should this maybe on by default for thehead
job?Having to put this into the
cabal.haskell-ci
brings the risk that it remains there forgotten while GHC has long progressed beyond 9.6. What I would really want to put there is!= head
or so. But I would argue that this could be the default.