Configure from configuration

[mikeshultz]

Overview

Allow configuration by network similar to geth provider.

Specification

Something like this would be cool:

alchemy:
  ethereum:
    mainnet:
      uri: https://eth-rinkeby.alchemyapi.io/v2/API_KEY

Or if you feel strongly about using keys instead of JSON-RPC URIs:

alchemy:
  ethereum:
    mainnet:
      api-key: API_KEY

Or maybe both?

There's probably some security concern here. It's not ideal if these keys are committed to public repos for an Ape project. However, I think that should be a decision for users to make (they may encrypt the config in their worfklow or use private repos and share keys between the team for dev purposes).

Dependencies

Not a hard dep, but I think this would gel well with a global config: https://github.com/ApeWorX/ape/issues/379.

[antazoey]

Hello! Thanks for this. I have some questions:

1. Why do you want to connect mainnet to rinkeby? I don't think this will work, but maybe that is just a typo
2. Is there a specific reason you don't like the environment variables?

But! Let me divulge some of our plans and thoughts around similar topics:

1. We want global config support.
2. We want env var interpolation in the config
3. We want you to just straight up be able to put your env vars in your global config
4. We want a secret storage support, like another abstract class, where you can use env-vars, or keyring, or whatever you need.
5. We are going to add all the network support to each provider plugins for the networks they actually support

And when I say "we want", I mean "I have heard someone express or I myself express desire for this"

[mikeshultz]

Why do you want to connect mainnet to rinkeby? I don't think this will work, but maybe that is just a typo

Yeah, a typo, but it does beg the question whether the network should be derived from the provider/node not the config. But that's way out of scope here.

Is there a specific reason you don't like the environment variables?

A couple reasons.

1. I Very often I will use keys per project or piece of software. Especially with Alchemy, you get separate metrics and separate rate limits (sometimes) per projects. Perhaps you also may want to use different keys between "work" and "home" or whatever. Having to set/unset env vars all the time can be difficult.
2. Networks, especially. With Alchemy you do not get an overall key but create a key for each network/app whatever.

Here's my current personal dashboard as an example:

Each of these represent a different Alchemy app, each with a unique key/endpoint.

Other thoughts sound cool. Some kind of secret store could be valuable, especially if you share things like Alchemy keys across a team which I think is pretty common.

We are going to add all the network support to each provider plugins for the networks they actually support

Not sure what you mean by this though.