haskell
Add fake-depends
Describe the feature request
fake-depends is a field like build-depends which would constraint solver, but otherwise do nothing.
It's sometimes (rarely, but nevertheless) needed to add a constraint, but the dependency is not (at least directly) used anywhere. It would be great if .cabal format had a way to explicitly specify that.
One (bad) example is to use fake-depends: QuickCheck with build-depends: tasty-quickcheck. You can import everything through tasty-quickcheck re-exports, but you may need to constraint underlying QuickCheck. Arguably tasty-quickcheck shouldn't re-export anything, or at least properly version own (re)exports. But here we are.
See export-depends in #11052 for another semantically more precise dependency specification field.
Similar example: A dependency d has an incorrect bound on t (e.g. no upper bound), hence the user of d may currently need to add a dependency on t -- just to tighten the bound -- even though t is purely transitive. I recall having to do this when aeson-2 came out.
Bikeshedding: Could also be called solver-depends, solving-depends.
I'm not convinced this belongs in cabal. For sure, I actually make use of the first example (did so 2 days ago, in fact), but I just used build-depends and disabled -Wall since my App.hs was main = putStrLn "hi". The other example is best covered by using cabal.project.local while petitioning the Hackage trustees for a metadata update on the broken package; doing it in a cabal file not only distributes the pain to victims, it hides the symptoms of the actual problem.
@geekosaur
Suggesting -Wno-.... is not an option. The .cabal format should allow us to express things in a way so we don't need to disable legit warnings. (Of course ignoring a warning is an option, but there SHOULD be a way to do things "correctly").
using cabal.project.local is not an option for packages to be uploaded on Hackage. We "bundle" the extra constraints into uploaded metadata. And this issue is exactly about being able to do that.
(Don't mix Cabal and cabal-install issue. cabal.project.local won't work for stack users / Stackage curators).
@gbaz No. export-depends is for reexported-modules. If export-depends is changed to fake-depends reexported-modules could break.
In other words, export-depends is not true build-depends (GHC doesn't care while compiling the modules), but its not "fake" dependency. It must be written to package configuration file for re-exported modules to exist.
fake-depends only constraint the solver.
I need this because of hashable: I depend on it transitively and observe different hashing of things, which makes me unable to write tests (sans workarounds like testing against several possibilities). I'd rather pin hashable to something producing a known-in-advance result.
The only thing I truly dislike about this is the name.
That said, I realized on looking things over that cabal's own test suite would benefit from it: see https://github.com/haskell/cabal/blob/master/cabal-testsuite/cabal-testsuite.cabal#L122-L150 .
I'm not attached to the name, any better suggestions? Maybe phantom-depends, is it any better?
Sounds better to me, if only because we already have e.g. "phantom types" in the ecosystem. "Phantom" to me says it's not used directly but may be used indirectly, which seems to cover all the suggested use cases; "fake" just sounds like an ugly hack. Granting that the potential use I pointed to just above probably is one.
@geekosaur no it won't. Proposed semantics for fake-depends / phantom-depends is that they add constraints on the packages, but if those packages are not transitively needed by anything, they won't be included in the build plan.
I like phantom-depends more too. I was also thinking about trans-depends (or transitive-depends), but maybe it's too narrow of a view?..
Could the field just be called constraints, since the listed packages aren't treated as dependencies?
@sebright that is an option, but it could be quite confusing, as it would be different from the cabal.project one.