0.1.3.0 seems to generate empty hie.yaml files for cabal projects

[arianvp]

There seems to be a serious regression for me in this release.

it just generates a yaml file as follows:

cradle:
  cabal:

[arianvp]

Or is this a feature; because hie now supports cabal projects well enough?

[fendor]

While I am not sure this is part of the latest release, yes, these simple cabal cradles work very reliably since cabal-3.4.

[Avi-D-coder]

@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.

[arianvp]

Unfortunately the repo is proprietary but i'll try to make a reproducer tomorrow and post it here

[ocharles]

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?

[fendor]

My recommendation is to have a hie.yaml with

cradle:
  cabal:

I think it is the most reliable.

[Avi-D-coder]

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?

@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]

@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.

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.

[fendor]

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

[lf-]

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/.

[lf-]

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

[Avi-D-coder]

@ocharles did a minimal hie.yaml cradle: {cabal: {}} fix it?

[ocharles]

@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.

[FPtje]

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"

[Avi-D-coder]

@FPtje
I have just re-released 0.1.2.7 as 0.1.4.0.
0.1.3.0 is deprecated.