Adopt cabal-add?

[ulysses4ever]

Describe the feature request
People often ask for a programmatic way to manipulate parts of the cabal file, especially w.r.t dependencies. A recent tool, cabal-add, delivers on the particular task. Should it be integrated into cabal proper?

Additional context
cabal-add (a tool adding entries in build-depends without ruining formatting in a cabal file) is being integrated into HLS: Bodigrim/cabal-add#7 This confirms my feeling that there's a user base for this feature, however partial this feature is.

I tried to read the implementation (it's reasonably small and clean). It juggles between [Field Position] and GenericPackageDescription like no tomorrow, starting from:
https://github.com/Bodigrim/cabal-add/blob/267eb6802477076b64568bff774aa7833bcbfa7b/src/Distribution/Client/Add.hs#L202-L210

... as is expected in the absence of a holistic solution for exact parsing (cf. #7544).

The core of it is three "algorithms" to solve the task (add a dependency) that spread across the spectrum: accuracy --- robustness (e.g. the first algorithm preserves formatting the best but is more fragile than the others)

• https://github.com/Bodigrim/cabal-add/blob/267eb6802477076b64568bff774aa7833bcbfa7b/src/Distribution/Client/Add.hs#L403-L407
• https://github.com/Bodigrim/cabal-add/blob/267eb6802477076b64568bff774aa7833bcbfa7b/src/Distribution/Client/Add.hs#L450-L453
• https://github.com/Bodigrim/cabal-add/blob/267eb6802477076b64568bff774aa7833bcbfa7b/src/Distribution/Client/Add.hs#L472-L475

Given that all of them are Maybe, I assume, the tool doesn't guarantee success...

Maybe we should wait and see how the HLS feature fares and what its users think?

[geekosaur]

Sounds like, at least at first, it's a candidate for an external command.

I had been thinking about this myself, but without much consideration for formatting. The basic idea was to add a dependency with multiple ways to specify versioning:

• add [section:]dep, use current Hackage version in a ^>=
• add [section:]dep ver, use specified version with ^>=
• add [section:]dep ver1 ver2, specify a version range

[geekosaur]

Also, seems to me HLS has more of a specific need for dependency adding, just as it automatically adds imports.

[Bodigrim]

Given that all of them are Maybe, I assume, the tool doesn't guarantee success...

It pretty much always succeeds, unless Cabal file has an ancient, unsectioned format. Which is when there are no sections library / executable / test-suite, but everything (including build-depends) somehow happens on the top level.

[Mikolaj]

For context, this has been discussed before: https://discourse.haskell.org/t/cabal-add-extend-cabal-build-depends-from-the-command-line/7911/6

[dawkrish]

Any updates on this ?!

[ulysses4ever]

@dawkrish it was agreed in the cabal team at one point that it'd be good to wait and see about the adoption of cabal-add. We also want a more comprehensive solution to programmatically editing package descriptions along the lines requested here #7544 Sadly, cabal-add doesn't fit this bill: as the author of cabal-add acknowledges, the tool's approach is good for adding stuff but is tricky to extend to modifying/removeing stuff. We are wary of going through the trouble of figuring out adoption of an external tool that we know would be only a partial solution to an existing problem.

In the meantime, we'd love it if people tried it through our external commands interface https://cabal.readthedocs.io/en/3.14/external-commands.html

[dawkrish]

Okay got it ! So basically I can extend cabal binary to use cabal-add .
Would really love it gets into the main tool

[Bodigrim]

Sadly, cabal-add doesn't fit this bill: as the author of cabal-add acknowledges, the tool's approach is good for adding stuff but is tricky to extend to modifying/removeing stuff.

I was not comparing cabal-add capabilities to an exact printer (whatever you pay this word to mean) in the linked comment. Removing or modifying stuff in the presence of arbitrarily nested common stanzas and conditionals is tricky, period. An exact printer would not make it easy.

Consider the following Cabal file:

common foo 
  build-depends: base, containers

executable bar 
  import: foo 

executable quux
  import: foo

Now let's ask a hypothetical tool "remove containers dependency from bar". It cannot simply remove the dependency from bar, because it comes from a common stanza foo. And it cannot simply remove it from foo, because it is used in other component as well. Instead it should return something like

common foo 
  build-depends: base -- no containers

executable bar 
  import: foo -- unchanged

executable quux
  import: foo
  build-depends: containers -- new

If there are conditionals, nested imports, multiple build-depends sections, the task becomes ever trickier and hard to tackle in full. Thus my comment on Discourse.

That said, if we limit ourselves to a "naive" implementation ("just remove the dependency from all build-depends sections of a given component, do not recurse into common stanzas"), then it's fairly doable in the framework of cabal-add. It recently gained an ability to rename / replace things; removing is not much more difficult, it's just that no one asked for it yet.

---

I'm largely skeptical that an exact printer can solve any practical business ask better than cabal-add and other existing tools, see haskellfoundation/tech-proposals#65 (comment) and onwards.