Cardano-wallet: Support Jörmungandr as a backend target in CLI

[KtorZ]

Context

The CLI offers a command server for starting a wallet backend server. That server is intended to connect and work with a specific node backend. At the moment, the CLI necessarily spawns a server which solely supports cardano-http-bridge as a backend.

In the long run, we want the CLI to support many backends (at least 3 among: http-bridge, jormungandr and shelley Haskell).

Some example of an wallet layer initialization with Jörmungandr is available in jormungandr/test/integration/Main.hs

Decision

• Have Jörmungandr as an available backend for the CLI.

• The choice between the bridge and jörmungandr will happen at compile-time, with two separate binaries.

• Update our CI setup accordingly in order to build and deploy corresponding artifacts during release builds.

Acceptance Criteria

1. CI _must_ produce 2 executables during release deployment:
   
   
   
   • cardano-wallet with http-bridge
   
   
   • cardano-wallet with jörmungandr
   
   

---

Development Plan

• [x] For prototyping purposes, make minimal adjustments to exe/wallet/Main.hs so that it works with the jormungandr backend instead of the http-bridge backend.
• [x] From the knowledge gained by building the above prototype, identify which parts of exe/wallet/Main.hs are generic to both backends, and which are specific to just one backend.
• [x] Move all functionality that is generic to both backends out of cardano-wallet:exe:cardano-wallet and into the common cardano-wallet-cli library.
• [x] Fork cardano-wallet into the following variants:
  
  
  
  • cardano-wallet-http-bridge: depends on {cardano-wallet-cli, cardano-http-bridge}.
  
  
  • cardano-wallet-jormungandr: depends on {cardano-wallet-cli, cardano-jormungandr}.
  
  
• [ ] (@jonathanknowles in progress) Add --quiet CLI option to upstream jormungandr command. (aborted, ticket created on Jörmugandr's end. Will reconsider when ticket is resolved: input-output-hk/jormungandr#622)

• [x] When cardano-wallet launch is run with --quiet or --verbose options, pass through these options to jormungandr.

• [x] (@KtorZ) switch to use optparse-applicative

• [x] Turn CLI function comments into executable specifications
• [x] Parse node's URL (api prefix, base url and port) from the config file when using launch
• [ ] Allow passing a --node-api-prefix when using serve, default to "api" (abandoned)

PR

| Number | Base |
| --- | --- |
| #478 | master |
| #479 | master |
| #480 | master |
| #482 | master |
| #483 | master |
| #490 | master |
| #498 | master |
| input-output-hk/jormungandr#615 | master |
| #512 | master |
| #517 | master |
| #520 | master |
| #537 | master |

QA

• Jormungandr is now available via the executable cardano-wallet-jormungandr in a very similar fashion to the bridge.

• Fully tested via out integration scenarios & end-2-end tests (cf: #358)

• Our deployment script should also be ready to deploy a pre-compiled binary for both jormungandr and http-bridge: See .travis.yml here and here

[jonathanknowles]

@KtorZ wrote:

The choice between the bridge and jörmungandr will happen at compile-time with a compilation flag to produce two different binaries.

I'm just curious as to what's the rationale behind this decision? Why not handle the choice at run-time?

[KtorZ]

Because there's a lot of type-level machinery here. So, by not making a choice at compile time, we give up on a few possible GHC optimization and, we make the instantiation of the target backend much harder.
In addition, this was agreed business-wise to have separate executables for each target backend. The wallet isn't intended to work with more than one backend at a time, so we have in practice multiple wallet softwares.

[jonathanknowles]

Does this compilation-time choice entail the usage of #ifdef statements within our code? Or will we be able to separate out these different implementations at the module or package level?

[KtorZ]

That's not decided yet. I'd be more inclined for multiple packages, but CPP+ifdef could work too.

[jonathanknowles]

That's not decided yet. I'd be more inclined for multiple packages, but CPP+ifdef could work too.

I would be in favour of handling this at the package level, if possible.

I suspect (but could be wrong) that #ifdef statements don't play very nicely with tools for code introspection (such as haskell-ide-engine). I could be wrong about that though.

[jonathanknowles]

@KtorZ wrote:

The choice between the bridge and jörmungandr will happen at compile-time with a compilation flag to produce two different binaries.

Instead of using a compilation flag, why not just have two different executable targets (two different executable sections within cardano-wallet.cabal)? The two different executables could depend on a (mostly) common set of libraries.

[jonathanknowles]

Removed cardano-wallet-launcher from the acceptance criteria, as this no longer exists as a separate executable.

[jonathanknowles]

@KtorZ I'd like to confirm one thing: should the CLI commands should all be basically exactly the same? Or are there expected to be any differences in the calling conventions?

[KtorZ]

@jonathanknowles The only "discrepancy" we tolerate here are in the launch & serve commands, since they interact directly with the wallet backend. For Jörmungandr for instance, we will need a genesis block hash to be provided which isn't the case for the bridge.

[jonathanknowles]

@KtorZ

For Jörmungandr for instance, we will need a genesis block hash to be provided which isn't the case for the bridge.

Are we expecting the user to provide this hash (if so, how will they know what to provide?), or will we hard-code the hash and pass it to Jormungandr behind the scenes?

[KtorZ]

@jonathanknowles We'll need this to be provided by the user since we can't realistically know what the hash is going to be. Plus, in the early phases we are going to tweak and tweak the genesis file that the hash is constantly going to change.

In the long run, we might provide some hard-coded shortcut to refer to well-known hash like --mainnet or --testnet but there's no such thing yet.