search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.62k stars 693 forks source link

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

Open deepfire opened 5 years ago

deepfire commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

jbgi commented 4 years ago

related issue: https://github.com/haskell/cabal/issues/5444

patr-ck commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@Fuuzetsu mentions something similar in https://github.com/haskell/cabal/issues/5444#issuecomment-730153339. I guess the situation has improved, but not enough?