hashable patch interacts badly with --allow-newer

Me too. This affects Haskell-CI workflows for GHC 9.10, which utilise head.hackage: https://github.com/haskell-hvr/regex-tdfa/actions/runs/8306825242/job/22735340728?pr=59

Error: cabal-3.10.2.1: Failed to build hashable-1.4.3.0 (which is required by doctest-parallel-0.3.1). See the build log above for details.
...
[3 of 7] Compiling Data.Hashable.Class ( src/Data/Hashable/Class.hs, dist/build/Data/Hashable/Class.o, dist/build/Data/Hashable/Class.dyn_o )

src/Data/Hashable/Class.hs:167:1: error: [GHC-87110]
    Could not load module ‘System.OsString.Internal.Types’.
    It is a member of the hidden package ‘os-string-2.0.2’.
    Perhaps you need to add ‘os-string’ to the build-depends in your .cabal file.

My settings use an automatic flag for the doctest suite that would turn off doctest-parallel if the cabal constraint solver realized the problem with hashable. However, the failure happens when building hashable, not when doing the solving, and then of course cabal does not backtrack.

My initial attempt at checking in that patch was to always enable the os-string flag and force --allow-newer=filepath. This ended up going very poorly, however, as it would create broken build plans that attempt to reinstall unix (see here for one example). Try as I might, I could not get the build plan to work. The only way I could get it to work was to deliberately not allow newer versions of filepath.

Perhaps there is a cleaner way of handling this, but it's not yet obvious to me what that would be.

Would just making the flag default: True instead work?

Maybe. I vaguely recall trying just default: True without --allow-newer=filepath (among other combinations) without success, but my memory escapes me.

I just did some more testing with a version with default switched to True, and it seems to have fixed the problem I originally reported without causing any new problems.