Option --cabal to read configuration from a .cabal file?

[andreasabel]

Context: We are considering switching from hs-tags to ghc-tags, just because maintaining hs-tags is a bit burdensome (uses the GHC API, thus, breaks with each new GHC version):

• Switch to ghc-tags, retirehs-tags ? agda/agda#2932

hs-tags has option --cabal to read configuration from the library section of a .cabal file.
I see that ghc-tags requires information such as default-languages and default-extensions to be duplicated in the ghc-tags.yaml configuration file. This is a bit error-prone and contradicts the DRY principle.

Maybe the --cabal option functionality could be ported from hs-tags to ghc-tags.

[arybczak]

Would passing --cabal ignore the .yaml file?

How complex is that functionality to port/maintain?

[andreasabel]

Would passing --cabal ignore the .yaml file?

I haven't thought so far, but --cabal could pull in information which can then be omitted from the .yaml file. I wouldn't think it can fully replace it.

How complex is that functionality to port/maintain?

The core of that functionality seems rather small (the Cabal library does the heavy lifting):
https://github.com/agda/hs-tags/blob/4ccdfca089fa1fcc2e83c90a6d6930656911d699/Main.hs#L180-L201

[arybczak]

Let's say that using --cabal would ignore the config file ghc-tags.yaml and use the .cabal file instead, that should work out fine.

PRs are welcome 🙂

[andreasabel]

I think one would still want to have the possibility to exclude files/directories from the tags generation, so completely replacing the --config file would not be desirable by a --cabal option. Rather, I'd think that the info drawn from the .cabal file would be complemented by the config file.