In the meantime cabal-add-0.2 library has gained ability to add and rename modules. This is available only through API for integration with HLS; the executable interface remains unchanged.
5 Likes
…and another release, cabal-add-0.2.1. This drops a dependency on cabal-install-parsers and now uses cabal-install proper. It would be nice if someone gives the new release a spin with --project-file, as this is the functionality affected.
We used cabal-install-parsers to parse cabal.project and determine which Cabal files are listed there. Unfortunately, cabal-install-parsers fell behind Cabal-syntax and, more importantly, the syntax of cabal.project files has been recently extended with imports and conditionals, making it difficult for third-party tools to cope. I managed to use cabal-install as a library for this purpose, although its interface is far from being convenient for this task or stable across releases.
10 Likes
Is there a plan cabal-add becomes part of cabal official ? like it comes out of the box ?
2 Likes
Three years since the initial release cabal-add, the Cabal team still awaits for an exact printer.
This is surely a “perfect is the enemy of good” situation, right?
Ostensibly, cabal add works. It doesn’t exact-print but does a thing that works for it. So who cares? The hacky approach is isolated in a module. Aka it’s modular.
So I don’t get it. As an engineer.
1 Like
If my memory serves me right, it absolutely isn’t.
Cabal’s syntax handling rests on a gargantuan eldritch parser that aside from all the other things also handles versioning. Its parsing result isn’t even a “parsed Cabal file”, it’s a whole “package description”. I wouldn’t call this maintainable, let alone “good”.
The “perfect” solution would be an intermediate representation so that you don’t have to deal with any of that garbage. You’d simply query data at
"library"."build-depends", which would also give you the byte offsets for the raw file, which you’d then use to edit the file.
Though of course that’s just my definition of “perfect”, judging by recent discussions people are still looking to implement this functionality by overloading the everything-parser with extra goodness.
We only started in Octobor on it, before that the tech proposal was in limbo for like, 2 years? Now we’re intending to open up another cabal proposal soon because we came up with a better design then trees that grow on top of GPD. This would be the third major iteration. It’s just a lot harder if you want to do it in cabal proper and be mostly backwards compatible and also do the exact printing.
5 Likes
eh just slap a caveat on cabal add and call it a day imo. Getting the useful thing upstream but flawed seems valuable here.
Cabal now supports external commands: 4. External Commands — Cabal 3.12.1.0 User's Guide
So you should just be able to do cabal install cabal-add and then use cabal add as if it was part of cabal.
I don’t understand what do we mean here by ‘exact printer’
It means exactly what you think it does, and I too have no idea why its desirable or whether its even feasible over a data format that allows modification.
1 Like
It’s desirable because people want to be able modify part of a cabal file without reformating everything. In the cabal add case, someone might be upset if adding a dep stripped comments or newlines from the cabal file.
2 Likes
cabal-add perfectly preserves comments and whitespaces.
2 Likes
yes true
i think cabal’s CLI is hot garbage. hard and verbose to do common things. surprising behavior. etc.
maybe i build a suite of v3- external commands that use the underlying cabal infra (probably forked from v2) but with a better CLI.
then cabal v3-repl and friends would be super nice to use finally!
and - most importantly - that it’s called v3- would be super funny.
(dw, it will have cabal v3-add)
1 Like
I for one am interested in hearing more about the approach you settled on 
2 Likes
I too have been unhappy about Cabal CLI tooling: Files · python · combobulate.systems / cablah · GitLab so wrote a tool which parses cabal format files and outputs JSON, and another which formats that JSON back into the cabal format. I wrote it in Python “for fun” and out of curiosity with the “lark” library there and make no promises about code quality. It should work for both cabal.project and pkg.cabal files though it’ll strip your comments. I’ve used it somewhat successfully for changing common fields across lots of packages. Recommend piping its output into cabal-gild.
But I think the overall path forward for Cabal is first-class support of at least one “common” format in the first place. (I know there is hpack but I don’t like that it has a separate vocabulary for field names from cabal)
2 Likes