Executable configuration

[pepyakin]

Here is my brain dump on how polkadot-launch could be improved for me.

I mostly work on polkadot and cumulus and often use polkadot-launch. I have different workflows that I need to do. The way polkadot-launch allows to configure it is very limiting. To explain, here are the exact things I need to customize in the configuration.

Node Flavors & Paths. Since it's Rust and you gotta be multitasking, I have two instances of the same repo checked out at once. For example, I have polkadot and polkadot-2 checked out and built. The same applies for cumulus. To be able to quickly test the instance on what I am working on currently, I should be able to quickly launch binaries either from polkadot and cumulus or polkadot-2 and cumulus-2 directories. Sometimes, I find myself in a situation when I need polkadot and cumulus-2. Other times, I need to launch adder-collator (a simple collator that lives in the polkadot repo). It even happened that I needed to run a 3rd party collator.

This problem is further complicated by the fact, that the paths are absolute. That means that the set of configuration files are different between my personal & working machines.

Ports. Oftentimes, I just don't care about what are the ws ports. Other times, I just want my ports be assigned sequentially, like X, X+1, X+2, etc. And yet other times, I need specific ports to be assigned.

HRMP channels. Most of the times I do not need HRMP channels. Occasionally I do need them.

For some of these combinations I have long lived configuration files. For others, I alter an existing configuration. As you can imagine, this is repetitive and error prone.

Another problem is versioning. Not so long ago before I am writing this, configuration format was changed. What this meant for me is that all my configuration files are rendered broken.

It seems for me that these problems could be alleviated if configurations were specified programmatically. For simplicity, we could start with a barebones approach, where the configuration is given as:

function config(): Configuration {
    // ..
    // returns an object which is basically almost the same as today's configuration 
    // ..
}

It's easy to imagine how to keep working the existing way of specifying configuration.

In order to reap benefits of this change, one would need a number of helper definitions.

For starters, I'd define paths to the polkadot, cumulus, adder-collator and make them depend on some external configuration. This configuration specifies the base path on the local machine.

Next, there could be helpers to assign ports. For example,

let wsPorts = seqPorts(1337); // will be 1337, 1338, 1339
let ports = randomPorts();

[
{
  wsPort: wsPorts.get(),
  port: ports.get(),
  // ...
},
{
  wsPort: wsPorts.get(),
  port: ports.get(),
  // ...
],

That has a lot of boilerplate still. That's why we can envision a DSL based on a builder pattern.

Builder()
  .relaychain()
    .node() // assumes default port and authority. In this case say 9944 and --alice
    .node()
      .name("charlie")
      .wsPort(1337)
  .parachain(200)
    .balance('1M')
    .simpleNode(ADDER_COLLATOR) // assumes default port
    .node(CUMULUS_2) // assumes alice 
      .args("-lruntime=debug")
  .hrmp(200, 300)

IMHO, this a way more readable than what we currently have. Such a DSL can be at some later on be distributed with polkadot-launch itself.