Integrate Jörmungandr backend with CLI.

[jonathanknowles]

Issue Number

#357

Overview

This PR forks our wallet CLI into two separate executables:

1. cardano-wallet
   built with the cardano-wallet-http-bridge backend

2. cardano-wallet-jormungandr
   built with the cardano-wallet-jormungandr backend

Parts common to both executables are located within the cardano-wallet-cli library.

Usage Examples

Launching with HTTP bridge backend

stack exec cardano-wallet -- launch

Launching with Jörmungandr backend

stack exec cardano-wallet-jormungandr -- launch \
    --backend-port=8081 \
    --genesis-hash=dba597bee5f0987efbf56f6bd7f44c38158a7770d0cb28a26b5eca40613a7ebd \
    --genesis-block=lib/jormungandr/test/data/jormungandr/block0.bin \
    --node-config=lib/jormungandr/test/data/jormungandr/config.yaml \
    --node-secret=lib/jormungandr/test/data/jormungandr/secret.yaml

Work not tackled by this PR

There is a small amount of code duplication between both executables (the execServe functions in exe/wallet/http-bridge/Main.hs and exe/wallet/jormungandr/Main.hs are very similar). Ideally, we should reduce this duplication (probably suitable for a future PR).

[Anviking]

FYI, we can retrieve block0H ourselves

{-# LANGUAGE OverloadedStrings #-}
import Cardano.Wallet.Jormungandr.Network
import Cardano.Wallet.Primitive.Types
import Cardano.Wallet.Unsafe
import Data.Coerce
    ( coerce )

main :: IO ()
main = do
    mgr <- newManager defaultManagerSettings
    let j = mkJormungandrLayer mgr (BaseUrl Http "localhost" 8081 "/api")
    let absentParent = Hash "\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL"
    [block0H] <- unsafeRunExceptT $ getDescendantIds j absentParent 1
    block0 <- unsafeRunExceptT $ getBlock j (coerce block0H)
    print block0

[KtorZ]

Yes and no. We do want the user to provide it such that we can verify they match!

[KtorZ]

🤔 I think we're loosing the benefits of using docopt in a first place. I understand the need for removing duplication between both files yet I am not sure we are taking it to the right direction :/ .. It's probably the right time to switch to optparse-applicative for the CLI.

[jonathanknowles]

I think we're loosing the benefits of using docopt in a first place. I understand the need for removing duplication between both files yet I am not sure we are taking it to the right direction :/ .. It's probably the right time to switch to optparse-applicative for the CLI.

I completely agree. Looking forward to trying a different direction with optparse-applicative here.