Modernize command-line parsing with optparse-applicative

[mitchellwrosen]

Is there any interest in replacing the System.Console.GetOpt code with a more modern optparse-applicative style options parser? If so, hm - maybe I'll take a stab. It could be a lot of work for little benefit, unless the existing options parsing code is slowing people down.

[hvr]

@mitchellwrosen well for one, there's issue of incurring an additional dependency in lib:Cabal which becomes a ghc boot package -- but we can workaround that by vendoring a subset of optparse-applicative into lib:Cabal

More importantly we'd need to figure out if all CLI features we currently have, and those which we intend to have in the future (such as e.g. context-sensitive tab-completion, whose competition candidates are retrieved lazily on-demand; e.g. consider cabal new-build exe:<tab>) can be expressed in optparse-applicative's framework.

[quasicomputational]

I've entertained a similar thought, but I shelved it because of the backwards-compatibility concerns.

We'd want a really, really thorough test-suite for command-line parsing to feel comfortable, I think, so that would be a first step to moving towards a different parsing library. (Besides all the usefulness of more tests catching regressions early and all that.)

[mitchellwrosen]

@hvr I'm not 100% positive optparse-applicative can parse everything exactly as Cabal does, but certain features (like "forwarding" arguments to subcommands so that cabal blah --flag is the same as cabal --flag blah when cabal itself does not have a global --flag) come for free. There's also a bash completion framework that I haven't tried to use, but it does allow IO.

@quasicomputational Good point, extensively testing the existing CLI would be the first step to refactoring it.

[mmhat]

Note that this would also fix #1257.

[michaelpj]

Would this really incur additional boot dependencies? AIUI GHC needs Cabal, but not cabal-install, and presumably CLI parsing should live in cabal-install?

[andreabedini]

The cli parsing is a mess. cabal-install's is bolted on top of Cabal's. They literally share the same types.
Perhaps this is one more reason to move cabal-install to optparse-applicative, so we separate the two clis.
I am afraid it's a fair bit of work though, at least in terms of lines of code.
Also note that v1 and v2 commands have different code paths for cli parsing. Which adds another level of complexity.

[Bodigrim]

FWIW optparse-applicative is Applicative: you can inspect Parser to build a QuickCheck-style generator of arbitrary arguments, accepted by it. This could be helpful to test that a new command-line parser behaves similarly to the old one.

Isn't it time to bury v1- commands? https://mail.haskell.org/pipermail/cabal-devel/2020-September/010488.html suggests so.

[ulysses4ever]

Isn't it time to bury v1- commands?

Cf. #9107 (comment)