-
Notifications
You must be signed in to change notification settings - Fork 247
cabalProject'
: Consider cabalProjectLocal
even if cabalProject
argument is null
#1588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cabalProject'
: Consider cabalProjectLocal
even if cabalProject
argument is null
#1588
Conversation
…argument is null
Motivation? |
Sometimes you want to use |
Yes this is a bug. I thought it only affected |
Does cabal accept a |
It does (with a warning):
|
Do we want the same |
cabal only seems to print that warning when there is an error. I think we could write the |
Good. Then please include a note explaining that this behaviour matches cabal and we tested it. |
I've updated the PR |
bors try |
tryBuild failed: |
bors try is all green now. |
tryBuild failed: |
#1588 does not provide an implicit project the way cabal does. So for instance: ``` $ cabal unpack hello $ cd hello-1.0.0.2 $ echo 'constraints: hello<0' >cabal.project.local $ cabal build all Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] next goal: hello (user goal) [__0] rejecting: hello-1.0.0.2 (constraint from project config /Users/hamish/iohk/hello-1.0.0.2/cabal.project.local requires <0) [__0] rejecting: hello-1.0.0.1, hello-1.0 (constraint from user target requires ==1.0.0.2) [__0] fail (backjumping, conflict set: hello) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hello ``` So even though there was no `packages:` it is looking for the package in the default location (the default is `packages: ./*.cabal` according to the cabal docs). I also checked that including `packages:` in `.local` does not change the implicit `packages: ./*.cabal` with: ``` $ cabal unpack split $ echo 'packages: ./split-0.2.3.5' > cabal.project.local $ cabal build hello:exe:hello split:lib:split ```
I forgot this also avoids and IFD when I suggested it could be removed. See #1588
#1588 does not provide an implicit project the way cabal does. So for instance: ``` $ cabal unpack hello $ cd hello-1.0.0.2 $ echo 'constraints: hello<0' >cabal.project.local $ cabal build all Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] next goal: hello (user goal) [__0] rejecting: hello-1.0.0.2 (constraint from project config /Users/hamish/iohk/hello-1.0.0.2/cabal.project.local requires <0) [__0] rejecting: hello-1.0.0.1, hello-1.0 (constraint from user target requires ==1.0.0.2) [__0] fail (backjumping, conflict set: hello) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hello ``` So even though there was no `packages:` it is looking for the package in the default location (the default is `packages: ./*.cabal` according to the cabal docs). I also checked that including `packages:` in `.local` does not change the implicit `packages: ./*.cabal` with: ``` $ cabal unpack split $ echo 'packages: ./split-0.2.3.5' > cabal.project.local $ cabal build hello:exe:hello split:lib:split ```
#1588 does not provide an implicit project the way cabal does. So for instance: ``` $ cabal unpack hello $ cd hello-1.0.0.2 $ echo 'constraints: hello<0' >cabal.project.local $ cabal build all Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] next goal: hello (user goal) [__0] rejecting: hello-1.0.0.2 (constraint from project config /Users/hamish/iohk/hello-1.0.0.2/cabal.project.local requires <0) [__0] rejecting: hello-1.0.0.1, hello-1.0 (constraint from user target requires ==1.0.0.2) [__0] fail (backjumping, conflict set: hello) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hello ``` So even though there was no `packages:` it is looking for the package in the default location (the default is `packages: ./*.cabal` according to the cabal docs). I also checked that including `packages:` in `.local` does not change the implicit `packages: ./*.cabal` with: ``` $ cabal unpack split $ echo 'packages: ./split-0.2.3.5' > cabal.project.local $ cabal build hello:exe:hello split:lib:split ```
#1588 does not provide an implicit project the way cabal does. So for instance: ``` $ cabal unpack hello $ cd hello-1.0.0.2 $ echo 'constraints: hello<0' >cabal.project.local $ cabal build all Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] next goal: hello (user goal) [__0] rejecting: hello-1.0.0.2 (constraint from project config /Users/hamish/iohk/hello-1.0.0.2/cabal.project.local requires <0) [__0] rejecting: hello-1.0.0.1, hello-1.0 (constraint from user target requires ==1.0.0.2) [__0] fail (backjumping, conflict set: hello) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hello ``` So even though there was no `packages:` it is looking for the package in the default location (the default is `packages: ./*.cabal` according to the cabal docs). I also checked that including `packages:` in `.local` does not change the implicit `packages: ./*.cabal` with: ``` $ cabal unpack split $ echo 'packages: ./split-0.2.3.5' > cabal.project.local $ cabal build hello:exe:hello split:lib:split ```
I haven't tested this.