Open arianvp opened 1 year ago
Or is this a feature; because hie
now supports cabal projects well enough?
While I am not sure this is part of the latest release, yes, these simple cabal cradles work very reliably since cabal-3.4
.
@arianvp can you post the repo this occurred on? This is not the intended behavior.
The logic in the latest release generates a component per module. Rather than just using the cabal file so a whole repo will be needed to reproduce the issue.
It's likely this issue is triggered by the structure of your repo, and the new logic does not correctly find modules.
Unfortunately the repo is proprietary but i'll try to make a reproducer tomorrow and post it here
Since upgrading to 0.1.3 we are also experiencing this at CircuitHub. Unfortunately it's also a proprietary repository, but am I right in thinking I only need the .cabal
and cabal.project
files to debug?
My recommendation is to have a hie.yaml with
cradle:
cabal:
I think it is the most reliable.
Since upgrading to 0.1.3 we are also experiencing this at CircuitHub. Unfortunately it's also a proprietary repository, but am I right in thinking I only need the
.cabal
andcabal.project
files to debug?
@ocharles With #48, we "generate one hie-bios component per module, instead of one per hs-source-dir". So without files a empty cradle will be returned. Is the empty cradle causing issues in HLS at CircuitHub? If this is the case I would suggest using a old version of gen-hie
and committing that hie.yaml
.
There's clearly an issue with generating cradles for cabal projects, since the repo mentioned in #48 also produces a empty cradle. I'm not sure how urgently a fix is needed, since a empty cradle should just work now days.
How would people feel about restoring the old one cradle per hs-source-dir
behavior under a flag --cabal-full-cradle
, and defaulting cabal projects to:
# If you run into any issues this file with `gen-hie --cabal-full-cradle`
cradle:
cabal:
@ocharles With https://github.com/Avi-D-coder/implicit-hie/pull/48, we "generate one hie-bios component per module, instead of one per hs-source-dir". So without files a empty cradle will be returned. Is the empty cradle causing issues in HLS at CircuitHub? If this is the case I would suggest using a old version of gen-hie and committing that hie.yaml.
The problem we're seeing is that without a hie.yaml
file at all, HLS doesn't work (I get no prefixes matched). Reverting back to pre-0.1.3 seems to fix this. If you think that a minimal hie.yaml
with cradle: {cabal: {}}
should fix this, I'm happy to go with that.
How would people feel about restoring the old one cradle per hs-source-dir behavior under a flag --cabal-full-cradle, and defaulting cabal projects to
Sounds good to me.
For accurate cradle generation for cabal projects, let's also not forget: https://github.com/phadej/cabal-extras/tree/master/cabal-hie
I regularly do major crimes to cabal projects such that I have overlapping cradle paths (test-dev
with source-dirs of both src
and test
, test
with just the test source dir, and lib
with the src
source dir), the non test-dev
ones of which has abysmal performance on the work codebase and need to be manually edited out.
So I really need the one-per-source-dir thing: I use gen-hie
to enumerate all the source dirs and targets for me, which I can then fix up by hand.
This situation is due to using various combinations of https://jade.fyi/blog/nix-hls-for-deps/ ("YOLO method") and https://jade.fyi/blog/cabal-test-dev-trick/.
The reason the one-per-module isn't really feasible is that there's 50000 lines of that so it's not editable (some of which is probably duplicated due to the above mentioned overlapping targets):
dev/large-closed-source-work-project » gen-hie | wc -l
51046
@ocharles did a minimal hie.yaml
cradle: {cabal: {}}
fix it?
@Avi-D-coder I removed my implicit-hie < 0.1.3
constraint from my haskell-language-server
build, and can confirm that haskell-language-server
no longer throws an error if I have the mentioned hie.yaml
. If I remove hie.yaml
, haskell-language-server
fails to compile anything (erroring with No prefixes matched
). I'm happy to use hie.yaml
.
It looks like this is not just for cabal projects. Since 0.1.3.0
gen-hie produces this for a proprietary stack project:
cradle:
stack:
For Stack, the above trick of cradle: {stack: {}}
does not work. Running haskell-language-server-9.2.4
then fails with the following error:
Severity: DsError
Message:
Failed to parse result of calling stack
* * * * * * * *
The main module to load is ambiguous. Candidates are:
1. Package `subproject' component subproject:exe:subproject with main-is file:
/home/my_user/my_projects_dir/my_project/subproject/executables/subproject.hs
2. Package `othersubproject' component othersubproject:exe:othersubproject with main-is file:
/home/my_user/my_projects_dir/my_project/othersubproject/executables/Main.hs
You can specify which one to pick by:
* Specifying targets to stack ghci e.g. stack ghci subproject:exe:subproject
* Specifying what the main is e.g. stack ghci --main-is subproject:exe:subproject
* Choosing from the candidate above [1..2]
* * * * * * * *
<stdin>: hGetLine: end of file
Reverting to an older version of gen-hie
, generating the following hie.yaml
and using that works:
cradle:
stack:
- path: "my_project/library"
component: "my_project:lib"
- path: "my_project/tests"
component: "my_project:test:my_project-tests"
- path: "subproject/library"
component: "subproject:lib"
- path: "subproject/./executables/subproject.hs"
component: "subproject:exe:subproject"
- path: "subproject/./Paths_subproject.hs"
component: "subproject:exe:subproject"
- path: "subproject/tests"
component: "subproject:test:subproject-tests"
- path: "othersubproject/library"
component: "othersubproject:lib"
- path: "othersubproject/./executables/Main.hs"
component: "othersubproject:exe:othersubproject"
- path: "othersubproject/./Paths_othersubproject.hs"
component: "othersubproject:exe:othersubproject"
- path: "othersubproject/tests"
component: "othersubproject:test:othersubproject-tests"
@FPtje
I have just re-released 0.1.2.7
as 0.1.4.0
.
0.1.3.0
is deprecated.
There seems to be a serious regression for me in this release.
it just generates a yaml file as follows: