feat(`cast`, `anvil`): add CLI flag to read an array of labels from a file

[ngotchac]

Component

Cast, Anvil

Describe the feature you would like

The labeling feature is awesome, but managing it directly in foundry.toml is not the right place when working with a lot of contracts. An option (in foundry.toml directly, or via a CLI arg) to set a filepath as somewhere to read labels from, whether JSON formatted, or maybe CSV, would be great!

It would enable using https://github.com/dawsbot/eth-labels easily for example, without having to import it directly in this repo/at build time. It would enable us to generate such a "labels" file for our own use cases.

This might relate to this issue: #640

Additional context

No response

[grandizzy]

Hey @ngotchac I think this makes sense for a vm.loadLabels(file) cheatcode one could call in setup. Are you looking for json or csv robot support? Cc @zerosnacks wdyt?

[ngotchac]

Thanks for the prompt reply. In our use case, we are not using cheatcodes, but mostly cast run and the likes, so it would be in the config file, and/or as a CLI arg.

[zerosnacks]

It may make sense that instead of creating a specific implementation that takes a CSV / JSON / TSV / TOML file we specify a format as "label_name:address,label_name:address" that you can then pipe into the command using regular UNIX tools. It is the user's responsibility to parse whatever way they have defined it and convert it into this format.

[ngotchac]

I'm not sure it's the best option, since :

1. There might be some arguments size limits when running a command with this as a list, since it could contain a lot of labels (eg. https://github.com/dawsbot/eth-labels/blob/v1/data/csv/accounts.csv contains 5MB of data)
2. It's not really convenient to always have to provide the list as an arg, even more so when it needs preprocessing, when running a cast command for example.

[zerosnacks]

I see, yes the argument size limit would constrain the amount of labels you can pass in. I think we could reasonably support JSON / TOML.

The proposed schema would be:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "LabelsConfig",
  "type": "object",
  "properties": {
    "labels": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "address": {
            "type": "string",
            "pattern": "^0x[a-fA-F0-9]{40}$"
          },
          "label": {
            "type": "string"
          }
        },
        "required": ["address", "label"],
        "additionalProperties": false
      }
    }
  },
  "required": ["labels"],
  "additionalProperties": false
}

example JSON:

{
  "labels": [
    {
      "address": "0x01d9f4d104668cdc0b6d13c45dff5e15d58d8f28",
      "label": "0x: MultiSig 2"
    },
    {
      "address": "0x06adaff9c864eb59ade310bc21150a8f4d5d4ab4",
      "label": "0x: WBTC Merchant Deposit Address"
    }
  ]
}

example TOML:

labels = [
  { address = "0x01d9f4d104668cdc0b6d13c45dff5e15d58d8f28", label = "0x: MultiSig 2" },
  { address = "0x06adaff9c864eb59ade310bc21150a8f4d5d4ab4", label = "0x: WBTC Merchant Deposit Address" }
]

Perhaps the chainId field could be an optional field that we can filter / match against