avi-d-coder / implicit-hie

Auto generate a stack or cabal multi component hie.yaml file

implicit-hie

cd your-stack-or-cabal-package
stack install implicit-hie # or cabal install implicit-hie
gen-hie > hie.yaml

gen-hie should be run the root of a cabal or stack project. The config type (cabal or stack) is determined by the existence of dist-newstyle, .stack-work, stack.yaml, if none are found the default is cabal. You can use --cabal, or --stack options to override config type.

Cabal Multi project example

❯ git clone https://github.com/well-typed/optics.git
❯ cd optics
❯ gen-hie
cradle:
  cabal:
    - path: "indexed-profunctors/src"
      component: "lib:indexed-profunctors"

    - path: "optics-th/src"
      component: "lib:optics-th"

    - path: "optics-th/tests"
      component: "optics-th:test:optics-th-tests"

    - path: "optics-vl/src"
      component: "lib:optics-vl"

    - path: "codegen/./Subtypes.hs"
      component: "optics-codegen:exe:optics-codegen-subtypes"

    - path: "optics-core/src"
      component: "lib:optics-core"

    - path: "optics-sop/src"
      component: "lib:optics-sop"

    - path: "optics-extra/src"
      component: "lib:optics-extra"

    - path: "template-haskell-optics/src"
      component: "lib:template-haskell-optics"

    - path: "optics/src"
      component: "lib:optics"

    - path: "optics/tests"
      component: "optics:test:optics-tests"

    - path: "metametapost/src/Cli.hs"
      component: "metametapost:exe:metametapost-optics"

Features

All common Cabal and Stack configurations should just work. If you use more advanced features, the generated config may not be complete.

• multi component cabal, stack projects
• multiple executables under a single path
• multiple paths provided to hs-source-dirs
• lookup nested packages in cabal.project or stack.yaml
• Handle Exe and Bench other-modules
• common stanzas

Work, Twitter

• Follow me on twitter @AviDessauer.

implicit-hie's Issues

Empty `other-modules` leads to wrong output

We have a stanza like this:

executable prism-unlock-exchange
    hs-source-dirs: prism/unlock-exchange
    other-modules:
    build-depends:
        base >=4.9 && <5

which gives output like this:

    - path: "plutus-scb/prism/unlock-exchange"
      component: "plutus-scb:exe:prism-unlock-exchange"
    - path: "plutus-scb/prism/unlock-exchange/build-depends:.hs"
      component: "plutus-scb:exe:prism-unlock-exchange"
    - path: "plutus-scb/prism/unlock-exchange/base.hs"
      component: "plutus-scb:exe:prism-unlock-exchange"

i.e. it's taking the cabal syntax after other-modules as, well, modules.

Not sure if this is related to #17.

Upload to hackage

Now that we are suggesting in hls the tool to help generate the hie.yaml, it would be great that users could install it with stack or cabal, without having to checkout the project.

Handle local tarballs in `cabal.project`

see haskell/haskell-language-server#3074

implicit-hie doesn't recognize foreign-library sections in cabal

I was attempting to follow the tutorial at https://nokomprendo.gitlab.io/posts/tuto_075/2021-09-12-fr-README.html

HLS is flagging the Binding module with Multi Cradle: no prefixes matched. The module is listed in the other-modules section of a foreign-library section in the cabal file, as follows:

foreign-library fibohs
    type:               native-shared
    cc-options:         -std=c++17
    c-sources:          cbits/binding.cpp
    install-includes:   cbits/binding.hpp
    hs-source-dirs:     ffi
    build-depends:      ffi, base
    other-modules:      Binding

Adding this hie.yaml

cradle:
  cabal:

fixes the problem, which indicates this is a problem with implicit-hie.

Adapt module structure to mirror hie-bios

Structure in hie-bios: HIE/...
Implicit-hie: Hie/...

I think this is needlessly inconsistent

`implicit-hie-cradle` mis-detecting cabal projects as stack projects

I'm struggling to pin down the issue here, but these are my observations:

• HLS was mis-detecting the cradle for https://github.com/input-output-hk/ouroboros-network: haskell-language-server --print-cradle was showing a stack cradle despite there being nothing stack-related there.
• Building HLS with implicit-hie < 0.1.3.0 gives the correct info.
• However, both gen-hie from implicit-hie-0.1.3.0 and hie-bios give the right cradle. This is using the same build plan as the HLS that doesn't work!

The only conclusion I can come to is that implicit-hie-0.1.3.0 broke implicit-hie-cradle which is what HLS uses. But I'm generally mystified.

Don't generate a Cradle based on .cabal file if cabal version >= 3.4

Since haskell/cabal#6622 has been merged, cabal repl works reliably for file paths that are part of a cabal project. Thus, implicit-hie should generate (at least within HLS) only the most basic cabal cradle, and not attempt parsing .cabal file and generate a multi-cradle based on the .cabal file.

This way we reduce the surface for errors in implicit-hie quite considerably. (probably a bit faster too)

For the gen-hie utility, probably nothing should be changed.

Common stanzas are not understood

What about using Cabal to do the parsing?

Operate on cabal project files not called cabal.project

Cabal has a flag --project, but it seems that there's not any way of using that with implicit-hie.

The practical use case of --project is when you may have a nix vs non-nix dependency setup, for instance.

If I have both then can I pick stack?

I have a project I build with both cabal v2 and stack. Could we please supplement the logic here so that if I have both then there's a way for me to choose stack?

implicit-hie/app/Main.hs

Lines 23 to 28 in 88e8f1c

	let name =
	if | any (("dist-newstyle" ==) . takeFileName) files -> "cabal"
	| any ((".stack-work" ==) . takeFileName) files -> "stack"
	| any (("cabal.project" ==) . takeFileName) files -> "cabal"
	| any (("stack.yaml" ==) . takeFileName) files -> "stack"
	| otherwise -> "cabal"

stack cradle does not discover .cabal files if they are deeper than 1 subdirectory

• from haskell/haskell-language-server#382 (comment)
• project structure and tests done by @comlyue copied from the issue

cymp:edh-universe cyue$ cat stack.yaml

# Please change the resolver and other Stack settings per your needs
resolver: lts-16.11

ghc-options:
  elr: -O0
  edh: -O0

## FOLLOWING CONTENTS GONNA BE OVERWRITTEN BY EPM ##

local-bin-path: /fw/m3cyue/edh-universe/bin
packages:
 - /fw/m3cyue/edh-universe/e-wrks/edh/lossless-decimal
 - /fw/m3cyue/edh-universe/e-wrks/edh/elr
 - /fw/m3cyue/edh-universe/e-wrks/edh/host.hs
 - /fw/m3cyue/edh-universe/e-wrks/nedh/host.hs
 - /fw/m3cyue/edh-universe/e-wrks/sedh/host.hs
 - /fw/m3cyue/edh-universe/e-wrks/hasdim/host.hs
 - /fw/m3cyue/edh-universe/e-wrks/haskit/host.hs
 - /fw/m3cyue/edh-universe/e-wrks/els/host.hs
cymp:edh-universe cyue$

cymp:edh-universe cyue$ find . -name \*.cabal
./e-wrks/edh/lossless-decimal/lossless-decimal.cabal
./e-wrks/edh/elr/elr.cabal
./e-wrks/edh/host.hs/edh.cabal
./e-wrks/nedh/host.hs/nedh.cabal
./e-wrks/sedh/host.hs/sedh.cabal
./e-wrks/hasdim/host.hs/hasdim.cabal
./e-wrks/haskit/host.hs/haskit.cabal
./e-wrks/els/host.hs/els.cabal
cymp:edh-universe cyue$

cymp:edh-universe cyue$ gen-hie
gen-hie: No .cabal files found under/fw/m3cyue/edh-universe
 You may need to run stack build.
CallStack (from HasCallStack):
  error, called at app/Main.hs:32:21 in main:Main
cymp:edh-universe cyue$ 

cymp:edh-universe cyue$ cd e-wrks/els/host.hs
cymp:host.hs cyue$ gen-hie
gen-hie: user error (InvalidYaml (Just (YamlException "Yaml file not found: /fw/m3cyue/edh-universe/e-wrks/els/host.hs/stack.yaml")))
cymp:host.hs cyue$ 

Confusing parsing behaviour when a list is the last thing in the .cabal file

I ran into some rather confusing behaviour when I used gen-hie with a cabal file that ended with an other-modules list. I loaded Hie.Cabal.Parser into GHCi to confirm this.

Test cabal file (to be parsed with/without a final newline):

name: foo
executable bar
  main-is: Main.hs
  other-modules: Hello
               , World

This file seems to miss World both with/without the final newline.

λ> parsePackage' "name: foo\nexecutable bar\n  main-is: Main.hs\n  other-modules: Hello\n               , World"
Right (Package "foo" [Comp Exe "bar" "./Main.hs",Comp Exe "bar" "./Hello.hs"])

λ> parsePackage' "name: foo\nexecutable bar\n  main-is: Main.hs\n  other-modules: Hello\n               , World\n"
Right (Package "foo" [Comp Exe "bar" "./Main.hs",Comp Exe "bar" "./Hello.hs"])

Test cabal file (to be parsed with/without a final newline):

name: foo
executable bar
  main-is: Main.hs
  other-modules: Hello,
                 World

This file is parsed different with/without a final newline:

λ> parsePackage' "name: foo\nexecutable bar\n  main-is: Main.hs\n  other-modules: Hello,\n                 World"
Right (Package "foo" [Comp Exe "bar" "./Main.hs"])

λ> parsePackage' "name: foo\nexecutable bar\n  main-is: Main.hs\n  other-modules: Hello,\n                 World\n"
Right (Package "foo" [Comp Exe "bar" "./Main.hs",Comp Exe "bar" "./Hello.hs",Comp Exe "bar" "./World.hs"])

Add travis-ci

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

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

it just generates a yaml file as follows:

cradle:
  cabal:

Comments in source directory sections are included in the output

e.g.

hs-source-dirs:
  foo
  -- need to include this too
  bar

Gives you a whole bunch of garbage entries like

  - path "<component>/--"
    component: <component>
  - path "<component>/need"
    component: <component>
...

Glob on directories where sensible

If a directory is only used by a single component, would it make sense to just attach that directory to a component, instead of listing the files in there individually? This might mean neater hie.yaml files, as well as be a bit more resilient to extra files appearing.

User error: key "packages" not found

When a stack.yaml file is missing the packages field, gen-hie will fail with the following error:

gen-hie: user error (AesonException "Error in $: key \"packages\" not found")

When adding the following to the stack.yaml file:

packages:
  - .

gen-hie works just fine. This seems redundant, though. Would it be possible to assume the singleton list containing . as default?

Enable travis-ci

So that it is visible on PRs.

https://travis-ci.org/

Support import-dirs under Cabal flags

Since the introduction of Cabal flags in haskell-language-server.cabal, gen-hie is not able to generate a cradle that covers all the import dirs in that Cabal descriptor. In particular, the folder plugins/default gets missed because its included conditionally.

I think that implicit-hie should consider all possible import-dirs, regardless of the flag default values.

Incorrect parsing of freeform fields

I posted the longer details here:

haskell/haskell-language-server#2012

but the gist is that freeform field lines that start with a "section" keyword are incorrectly parsed as sections.

I think I can come up with a half decent candidate patch, then you might want to tweak it and add some regression testing.

Executables with `other-modules` end up with incorrect paths

I have:

executable analyse-quoting
  ...
  other-modules:
    CircuitHub.Quoting.Analysis.AssemblyPricing.Picofactory2
    CircuitHub.Quoting.Analysis.CompetitorQuote
    CircuitHub.Quoting.Analysis.FinalOffers
    CircuitHub.Quoting.Analysis.QuoteParameters
    CircuitHub.Quoting.Analysis.Report
    CircuitHub.Quoting.Analysis.Sample

But when I run gen-hie I get:

    - path: "./quoting/exe-analyse-quoting/Main.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.AssemblyPricing.Picofactory2.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.CompetitorQuote.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.FinalOffers.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.QuoteParameters.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.Report.hs"
      component: "quoting:exe:analyse-quoting"

    - path: "./quoting/exe-analyse-quoting/CircuitHub.Quoting.Analysis.Sample.hs"
      component: "quoting:exe:analyse-quoting"

Which is wrong - these files don't exist.

Modules are sometimes listed explicitly for some reason

When I run gen-hie in the root of https://github.com/unisonweb/unison/tree/5ba4d052bc6f74dff66654266e09eb192de97be1, I get:

cradle:
  cabal:
    - path: "codebase2/codebase/./"
      component: "lib:unison-codebase"

    - path: "codebase2/codebase-sqlite/./"
      component: "lib:unison-codebase-sqlite"

    - path: "codebase2/codebase-sync/./"
      component: "lib:unison-codebase-sync"

    - path: "codebase2/core/./"
      component: "lib:unison-core"

    - path: "codebase2/util/./"
      component: "lib:unison-util"

    - path: "codebase2/util-serialization/./"
      component: "lib:unison-util-serialization"

    - path: "codebase2/util-term/./"
      component: "lib:unison-util-term"

    - path: "parser-typechecker/src"
      component: "lib:unison-parser-typechecker"

    - path: "parser-typechecker/prettyprintdemo/Main.hs"
      component: "unison-parser-typechecker:exe:prettyprintdemo"

    - path: "parser-typechecker/prettyprintdemo/Paths_unison_parser_typechecker.hs"
      component: "unison-parser-typechecker:exe:prettyprintdemo"

    - path: "parser-typechecker/tests/Suite.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Core/Test/Name.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/ABT.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/ANF.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Cache.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/ClearCache.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Codebase/Causal.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Codebase/Path.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/CodebaseInit.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/ColorText.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Common.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/DataDeclaration.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/FileParser.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/GitSync.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Lexer.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/MCode.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Range.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Referent.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Term.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/TermParser.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/TermPrinter.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Type.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Typechecker.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Typechecker/Components.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Typechecker/Context.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Typechecker/TypeError.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/TypePrinter.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Ucm.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/UnisonSources.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/UriParser.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Util/Bytes.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Util/PinBoard.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Util/Pretty.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Util/Relation.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/Var.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Unison/Test/VersionParser.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/tests/Paths_unison_parser_typechecker.hs"
      component: "unison-parser-typechecker:exe:tests"

    - path: "parser-typechecker/transcripts/Transcripts.hs"
      component: "unison-parser-typechecker:exe:transcripts"

    - path: "parser-typechecker/transcripts/Paths_unison_parser_typechecker.hs"
      component: "unison-parser-typechecker:exe:transcripts"

    - path: "parser-typechecker/unison/Main.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/unison/ArgParse.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/unison/Compat.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/unison/System/Path.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/unison/Version.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/unison/Paths_unison_parser_typechecker.hs"
      component: "unison-parser-typechecker:exe:unison"

    - path: "parser-typechecker/benchmarks/runtime/Main.hs"
      component: "unison-parser-typechecker:bench:runtime"

    - path: "parser-typechecker/benchmarks/runtime/Paths_unison_parser_typechecker.hs"
      component: "unison-parser-typechecker:bench:runtime"

    - path: "unison-core/src"
      component: "lib:unison-core1"

    - path: "yaks/easytest/src"
      component: "lib:easytest"

    - path: "yaks/easytest/tests/Suite.hs"
      component: "easytest:exe:runtests"

    - path: "yaks/easytest/tests"
      component: "easytest:test:tests"

As you can see, for some reason it's decided to list out every file in each executable 🤔

Not clear how to install or use

Hello,

I've installed implicit-hie by adding the following in stack.yaml:

extra-deps:
  - git: https://github.com/Avi-D-coder/implicit-hie # implicit-hie
    commit: fc1d3329148ea6616cd42d1919c5385a1a577af2

and in project.cabal:

executable descriptions
  build-depends:       ...,
                       ...,
                       implicit-hie,
                       base >= 4.7 && < 5

and running stack build.

When I type gen-hie into a terminal, I get a command not found: gen-hie error.

Is there something specific more to do? How can we declare where the executable should go?

Generates too many executables

Given

...

executable cachix-server
  import:         defaults
  main-is:        Main.hs
  other-modules:
    CollectMetrics
    DeleteNars
    ExpireTrials
    GarbageCollection
    GenElm
    Migrate
    SyncGitHub

  ...

It generates

cradle:
  stack:
    - path: "./exe/cachix-server/Main.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/CollectMetrics.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/DeleteNars.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/ExpireTrials.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/GarbageCollection.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/GenElm.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/Migrate.hs"
      component: "cachix-server:exe:cachix-server"

    - path: "./exe/cachix-server/SyncGitHub.hs"
      component: "cachix-server:exe:cachix-server"

Support both --stack and --cabal at the same time

I'm currently in a situation where a project is developed by a team. Some people use stack and others cabal. We use gen-hie as a pre-commit hook, so it would be nice if it can support both --cabal and --stack options to generate two cradles at the same time.

Taking the example from the README, the output would be something like this:

$ gen-hie --cabal --stack
cradle:
  cabal:
    - path: "indexed-profunctors/src"
      component: "lib:indexed-profunctors"

    - path: "optics-th/src"
      component: "lib:optics-th"

    - path: "optics-th/tests"
      component: "optics-th:test:optics-th-tests"

    - path: "optics-vl/src"
      component: "lib:optics-vl"

    - path: "codegen/./Subtypes.hs"
      component: "optics-codegen:exe:optics-codegen-subtypes"

    - path: "optics-core/src"
      component: "lib:optics-core"

    - path: "optics-sop/src"
      component: "lib:optics-sop"

    - path: "optics-extra/src"
      component: "lib:optics-extra"

    - path: "template-haskell-optics/src"
      component: "lib:template-haskell-optics"

    - path: "optics/src"
      component: "lib:optics"

    - path: "optics/tests"
      component: "optics:test:optics-tests"

    - path: "metametapost/src/Cli.hs"
      component: "metametapost:exe:metametapost-optics"

  stack:
    - path: "indexed-profunctors/src"
      component: "indexed-profunctors:lib"

    - path: "optics-th/src"
      component: "optics-th:lib"

    - path: "optics-th/tests"
      component: "optics-th:test:optics-th-tests"

    - path: "optics-vl/src"
      component: "optics-vl:lib"

    - path: "codegen/./Subtypes.hs"
      component: "optics-codegen:exe:optics-codegen-subtypes"

    - path: "optics-core/src"
      component: "optics-core:lib"

    - path: "optics-sop/src"
      component: "optics-sop:lib"

    - path: "optics-extra/src"
      component: "optics-extra:lib"

    - path: "template-haskell-optics/src"
      component: "template-haskell-optics:lib"

    - path: "optics/src"
      component: "optics:lib"

    - path: "optics/tests"
      component: "optics:test:optics-tests"

    - path: "metametapost/src/Cli.hs"
      component: "metametapost:exe:metametapost-optics"

Create a subcommand to gen a `hie.yaml` multi cradle to ignore `Setup.hs` to avoid haskell-language-server#3348

Error and fix: haskell/haskell-language-server#3348

include `gen-hie` binaries with releases?

Thanks for creating gen-hie, it is essential to a smooth HLS experience.

Would you be open to including pre-built binaries for gen-hie along with each release of implicit-hie? I'd like to use gen-hie in CI, and for this it would be great to have official binaries to point to, rather than waiting for cabal install implicit-hie each time.

If I understand correctly, this should require only a small change to the GitHub workflows, perhaps using hlint's release workflow as a guide.

If you like, I can put together a PR to get started.

Integrate Cabal-Helper

Since haskell/haskell-language-server#138 would render the Code in https://github.com/haskell/haskell-language-server/blob/master/src/Ide/Cradle.hs vastly obsolete, I would like to propose that this repo integrates Cabal-Helper, especially the CabalHelper Cradle.

A possible usage of Cabal-Helper in gen-hie would be to have two modes of generating a hie.yaml file:

• heuristic (parsing .cabal file, etc...)
• exact (using cabal-helper)

If you do not want to impose the dependencies on all consumers of this library, I think it would make sense to enable/disable the usage of cabal-helper via a cabal flag.

What this would bring:

• Move vast parts of Cradle.hs to this repo, making it a possible implicit cradle discovery mechanism.
• This repo becoming the only source of implicit cradle discovery.
• Add a flag to gen-hie to use an exact heuristic for creating hie.yaml files.

I think this may bring us the best of both worlds: a more error resilient implicit cradle discovery in HLS, and the more exact generation of hie.yaml with cabal-helper.

The PR haskell/haskell-language-server#138 is unaffected from this issue in general.
cc @jneira

Support curly braces

Cabal files apparently allows writing curly braces around blocks, which confuses implicit-hie. For example, this file: https://github.com/ivan-m/graphviz/blob/42dbb6312d7edf789d7055079de7b4fa099a4acc/graphviz.cabal#L59

Library {

-- ...

will generate a hie.yaml file like this

cradle:
  cabal:
    - path: "./"
      component: "graphviz:lib:{"

# ...

instead of the expected

cradle:
  cabal:
    - path: "./"
      component: "lib:graphviz"

# ...

Parsing `cabal.project` fails when its content is "packages: ..." without a trailing newline

gen-hie fails to parse cabal.project when it consists only of the field "packages" without a trailing newline.

Suppose that the current directly contains proj, which contains proj.cabal with certain content.

$ ls 
proj
$ ls proj 
LICENSE     app/        proj.cabal

Then, if we generate cabal.project whose content is "packages: ..." without a trailing newline, gen-hie fails to parse the file.

$ echo -n "packages: proj/*.cabal" > cabal.project
$ gen-hie
Used cabal
 No .cabal files found under/Users/kztk/prog/haskell/cabal_package_f
 You may need to run stack build.

On the other hand, if the cabal.project has a trailing newline, everything works as expected.

$ echo  "packages: proj/*.cabal" > cabal.project
$ gen-hie 
cradle:
  cabal:
    - path: "proj/app/Main.hs"
      component: "proj:exe:proj"

I confirmed the above issue with implicit-hie 0.1.4.0.

I suspect this issue would be caused by the function field called by extractPkgs in src/Hie/Cabal/Parser.hs, which requires the newline in the end by calling skipToNextLine.

Implicit hie fails to generate the main lib component due to package description

• Reported by @IvanMalison in irc
• Commit removing the description: taffybar/taffybar@257a620
• Description:

  Taffybar is a gtk+3 (through gi-gtk) based desktop information bar, intended
  primarily for use with XMonad, though it can also function alongside other EWMH
  compliant window managers. It is similar in spirit to xmobar, but it differs in
  that it gives up some simplicity for a reasonable helping of eye candy. 

• hie.yaml generated with the description (it misses the existing library component)

cradle:
  cabal:
    - path: "./app/Main.hs"
      component: "taffybar:exe:taffybar"

    - path: "./app/Paths_taffybar.hs"
      component: "taffybar:exe:taffybar"

I dont see at a first look what part of the decription is triggering the bug

Issues with cabal.project pointing to current directory

My cabal.project has:

packages:
    ./.
    ../reanimate-svg

implict-hie produces:

cradle:
  cabal:
    - path: "../reanimate-svg/src"
      component: "lib:reanimate-svg"

    - path: "../reanimate-svg/test"
      component: "reanimate-svg:test:w3c-spec"

When I'd expect:

cradle:
  cabal:
    - path: "./app/Main.hs"
      component: "svgone:exe:svgone"

    - path: "./src"
      component: "lib:svgone"

    - path: "../reanimate-svg/src"
      component: "lib:reanimate-svg"

    - path: "../reanimate-svg/test"
      component: "reanimate-svg:test:w3c-spec"

Which is actually what I get if I change ./. to .. But the latter isn't actually valid syntax - cabal gives:

cabal: Error parsing project file
/Users/gthomas/personal/svgone/cabal.project:1:
Parse of field 'packages' failed.

Package name not picked up

TLDR if I start package name with a newline then it's not picked up

So I indented my cabal file as follows

test1.cabal

cabal-version: 3.0

name:
  test
version:
  0.1

build-type:
  Simple

library
  exposed-modules:
    Foo
  hs-source-dirs:
    src
  build-depends:
    base >= 4.9

and got following from parsing

> parsePackage' <$> T.readFile "/tmp/test.cabal"
Right (Package "" [Comp Lib "" "src"])

However, if I change just one line then it parses (via Hie.Cabal.Parser) ok

test2.cabal

cabal-version: 3.0

name: test
version:
  0.1

build-type:
  Simple

library
  exposed-modules:
    Foo
  hs-source-dirs:
    src
  build-depends:
    base >= 4.9

> parsePackage' <$> T.readFile "/tmp/test2.cabal"
Right (Package "test" [Comp Lib "" "src"])

Since cabal accepts test1.cabal, I think it should be supported. What do you think?

Where does `gen-hie` come from

Hello
Maybe I am a dummy,

but I have no idea how to use gen-hie.
I am working in a virtual box. The os in the virtual box is ubuntu.

An explanation how to make gen-hie available would be nice.

gen-hie > hie.yaml
gen-hie: command not found

Best Regards

Multi Cradle: No prefixes matched2

Thanks for writing this utility!
I used it and it works wonders, but I get the above error for the "Paths_" module that cabal generates.

error: No prefixes matches for default hie in a simple project

I use vscode and have installed implicite-hie with cabal for ghc 8.10.4. when I start HLS in vscode I get the error message:

{
	"resource": "/home/frank/Workspace11/uniformBase/uniformSources/uniform-algebras/app/Main.hs",
	"owner": "Haskell (uniform-algebras)",
	"severity": 8,
	"message": "Multi Cradle: No prefixes matched\npwd: /home/frank/Workspace11/uniformBase/uniformSources/uniform-algebras\nfilepath: /home/frank/Workspace11/uniformBase/uniformSources/uniform-algebras/app/Main.hs\nprefixes:\n(\"src\",Cabal {component = Just \"lib:uniform-algebras\"})\n",
	"source": "cradle",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 2,
	"endColumn": 1
}

The project is build with cabal build and contains a trivial main in app and three modules in lib/uniform-algebra.

The same appears when I create the craddle with gen-hie > hie.yaml. The result is that HLS does not work for this directory (it works on other directories in other projects. What do I wrong?
Thank you for HLS.. when it works it is very helpful!