Depend on optparse-applicative instead of optparse-applicative-fork

[smelc]

Note

Requires a release of optparse-applicative > 0.18.1 to be merged

Changelog

- description: |
    Depend on optparse-applicative instead of optparse-applicative-fork
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

We want to get rid on our dependency to optparse-applicative-fork here: cardano-cli/cardano-cli.cabal#L245.

This PR does this, as well as showing what it happens if we take a vanilla version of optparse-applicative. This is what the commit Changes to golden files WITHOUT change to optparse-applicative shows.

Then the last commit, named Changes to golden files WITH change to optparse-applicative shows what we can achieve if we tweak optparse-applicative slightly. In this case the changes to golden files is minimal (pipes move to the left, and then are more single line disjunctions, but they are fine IMHO).

How to trust this PR

Look at the golden files. See that the end state is quite nice.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• Self-reviewed the diff

[smelc]

This PP.align value is the magical configuration bit that makes the golden files still look good. The changes in https://github.com/smelc/optparse-applicative/commits/smelc/wip-cardano-cli-usecase/ are hardcoding this configuration change for now, but my plan is to make a PR to optparse-applicative to make this configurable.

[smelc]

Because optparse-applicative should be released soon, we should be able to merge this PR soonish.

That is why I'm assigning it to you @nbacquey 🙂

[smelc]

This will be mergeable soon: pcapriotti/optparse-applicative#494 (comment)

cc @carbolymer @nbacquey

[smelc]

Seems this can be finished now: https://github.com/pcapriotti/optparse-applicative/releases/tag/0.19.0

cc @nbacquey @Jimbo4350

[carbolymer]

We're depending on cardano-addresses now, which depends on optparse-applicative. PR blocked on:

• Revise cardano-addresses in Hackage cardano-addresses#311

[Jimbo4350]

The change in the alignment is a decrease in readability IMO. Can we keep the previous alignment?

[Jimbo4350]

Why not import from Cardano.CLI.Type.Error.QueryCmdError?

[Jimbo4350]

Do we want this formatting change cc: @CarlosLopezDeLara

[Jimbo4350]

This seems like a decrease in readability.

[CarlosLopezDeLara]

@Jimbo4350 @carbolymer

I agree.

I do like the compactness of things like:

Usage: cardano-cli conway query protocol-parameters [--cardano-mode [--epoch-slots SLOTS]] (--mainnet | --testnet-magic NATURAL) --socket-path SOCKET_PATH [--output-json | --output-yaml] [--out-file FILEPATH] 

But in the other hand, the build command and others with more complex options are far too messy

Let's not merge this one. It was a good idea trying to remove the burden of maintaining the fork, but we loose readability.

[carbolymer]

This PR results in decrease in readabilty, which seems to be not feasible to fix with the current version of optparse-applicative-fork-0.19.