[RFC] Negative specification of cabal.project fields affecting package resolution

[deepfire]

In certain scenarios, where:

1. We have magical knowledge that the GHC's package set is sufficient to build the project, and
2. We still need the cabal.project for some extra information (flags, relative package locations etc)

We might want to:

1. suppress the aspects of project file's specification that affect package resolution,
2. and further, being able to express that suppression via cabal.project.local

Hence, I propose that we add two new directives to cabal project files:

1. ignore-source-repositories, that would have the effect of cancelling all effects of source-repository-package declarations
2. ignore-constraints, to cancel all effects of constraints declarations.

cc @dcoutts

[deepfire]

Duncan suggested we use conditional inclusion in cabal project files instead.

That would be indeed, strictly more expressive.

We could reuse the existing language for conditionals.

[phadej]

Note that conditional inclusion is not that simple, and needs proper specification (perfectly of all cabal.project format).

if impl(ghc >= 8.8)
  -- is this GHC 8.8 or not?
  with-compiler: /some/spooky/ghc

[deepfire]

Maybe we should reopen this, to keep the discussion alive -- after all, the underlying problem has not been resolved.

[jbgi]

related issue: #5444

[patr-ck]

Like @jgbi above, I'm trying to get nix-shell working with haskell.nix. My project builds just fine through nix-build, but running cabal inside the nix-shell is complaining that a "package is broken". This package depends on one I specified through source-respository-package in the cabal.project.

I modified cabal to print exactly what dependency is missing, which, in my case, looks like this MISSING: UnitId "jsaddle-webkit2gtk-0.9.7.0-4f5VrK6HKOW7EeOE3VOzPr"

When I ghc-pkg list -v, that package is shown: jsaddle-webkit2gtk-0.9.7.0 (jsaddle-webkit2gtk-0.9.7.0-4f5VrK6HKOW7EeOE3VOzPr)

Any suggestions?

[Ericson2314]

IMO the proposed fix is beating around the bush, what we really need to do is make clear the builds in the package database correspond with the source code they came from. So rather than tricking cabal-install into blindly accepting pre-built packages, it should knowingly accept them, fully aware they are not the usual Hackage ones.

With the "nix-style builds" cabal does, we shouldn't need any new metadata. Rather, we should just make sure the various hashes that exist already reflect this information.

[Ericson2314]

@Fuuzetsu mentions something similar in #5444 (comment). I guess the situation has improved, but not enough?