Skip to content

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

Merged
merged 2 commits into from
Sep 2, 2022

Conversation

L-as
Copy link
Contributor

@L-as L-as commented Aug 13, 2022

I haven't tested this.

@michaelpj
Copy link
Collaborator

Motivation?

@L-as
Copy link
Contributor Author

L-as commented Aug 16, 2022

Sometimes you want to use cabalProjectLocal without cabalProject?
This is just a plain bug, no?

@hamishmack
Copy link
Collaborator

Yes this is a bug. I thought it only affected hackage-project based things (that is where I found it annoying). Can you please remove the old work around here? I'm pretty sure this change will make that redundant.

@michaelpj
Copy link
Collaborator

Does cabal accept a cabal.project.local without cabal.project?

@hamishmack
Copy link
Collaborator

Does cabal accept a cabal.project.local without cabal.project?

It does (with a warning):

[nix-shell:~/iohk/hello-1.0.0.2]$ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

[nix-shell:~/iohk/hello-1.0.0.2]$ ls -l cabal.project
ls: cannot access 'cabal.project': No such file or directory

[nix-shell:~/iohk/hello-1.0.0.2]$ cat cabal.project.local
packages: test

[nix-shell:~/iohk/hello-1.0.0.2]$ cabal build all
Warning: both implicit and explicit configuration is present.When using configuration(s) from /Users/hamish/iohk/hello-1.0.0.2/cabal.project.local, the following errors occurred:
The package location 'test' does not exist.

@yvan-sraka
Copy link
Contributor

yvan-sraka commented Aug 18, 2022

Do we want the same Warning: both implicit and explicit configuration is present. warning when cabalProjectLocal is set and not cabalProject? (rather than just ignore cabalProjectLocal like this PR does?)

@hamishmack
Copy link
Collaborator

hamishmack commented Aug 18, 2022

cabal only seems to print that warning when there is an error. I think we could write the cabalProjectLocal to cabal.project.local to get the same behaviour. That is a bigger change though as it would require we correctly handle source-repository-package blocks in both files (rather than just combining them and parsing once).

@michaelpj
Copy link
Collaborator

Good. Then please include a note explaining that this behaviour matches cabal and we tested it.

@L-as
Copy link
Contributor Author

L-as commented Sep 1, 2022

I've updated the PR

@hamishmack
Copy link
Collaborator

bors try

iohk-bors bot added a commit that referenced this pull request Sep 2, 2022
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Sep 2, 2022

try

Build failed:

@hamishmack
Copy link
Collaborator

bors try is all green now.

iohk-bors bot added a commit that referenced this pull request Sep 2, 2022
@hamishmack hamishmack merged commit fc5a5b4 into input-output-hk:master Sep 2, 2022
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Sep 2, 2022

try

Build failed:

hamishmack added a commit that referenced this pull request Sep 2, 2022
#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
```
hamishmack added a commit that referenced this pull request Sep 2, 2022
I forgot this also avoids and IFD when I suggested it could be removed. See #1588
@hamishmack hamishmack mentioned this pull request Sep 2, 2022
hamishmack added a commit that referenced this pull request Sep 2, 2022
I forgot this also avoids and IFD when I suggested it could be removed. See #1588
hamishmack added a commit that referenced this pull request Sep 2, 2022
#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
```
hamishmack added a commit that referenced this pull request Sep 2, 2022
#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
```
hamishmack added a commit that referenced this pull request Sep 2, 2022
#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
```
@L-as L-as deleted the fix-cabal-project branch September 2, 2022 09:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants