Open ulysses4ever opened 2 months ago
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 rangeAlso, seems to me HLS has more of a specific need for dependency adding, just as it automatically adds imports.
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.
For context, this has been discussed before: https://discourse.haskell.org/t/cabal-add-extend-cabal-build-depends-from-the-command-line/7911/6
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 inbuild-depends
without ruining formatting in a cabal file) is being integrated into HLS: https://github.com/Bodigrim/cabal-add/issues/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]
andGenericPackageDescription
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. https://github.com/haskell/cabal/issues/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)
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?