feat(config): add config crate

[mattsse]

closes #291
Adds a config crate, see README for description

[gakonst]

I'm +1 on this design, plus other things like compiler optimizations, enabling of FFI etc.

[gakonst]

This is already looking really good. One thing we should do is:

1. Touch a default version of it during forge init
2. Make forge assume that the project root is where the foundry.toml is, instead of where the git project root is. It would traverse from the current directory up to the git root directory looking for a foundry.toml, and stop when it finds it. If none is found, it'll use the git root, and if that fails too, it'll throw an error indicating that nothing was found and that maybe the user should use another path. In the case that there's no git root, maybe we should cap the number of directories it can traverse up?

[mattsse]

sgtm!

traversing dirs is built in directly to figment and is definitely negligible, also considering that cargo does the same thing.
this will probably always be between 4-10 levels and dir lookups are quite fast.

[gakonst]

LGTM so far, minor nits. Just need to:

1. add it in forge init
2. add some docs about it in the top-level README, to guide ppl to start creating these config files in their dev envs
3. change the root dir detection from being the .git dir, to the first directory foundry.toml is found in OR the .git dir for a project.

[mattsse]

Updates

• extended config values and added a complete example in config/README
• support and optimize relative Remappings in foundry.toml, so that remappings can be added as remappings = ["ds-test=lib/ds-test/"], starting from the project root.
• updated main readme
• added forge config command to show the currently used values
• include BasicConfig in forge init
• add integration test for init

@gakonst

[mattsse]

Todo

• integrate Config::load in all commands

[gakonst]

LGTM - wonder if we should combine the new Remapping struct with the old one?

[gakonst]

think we should at a minimum have a list of the error codes somewhere, and what they correspond to? https://gist.github.com/onbjerg/a7d1243bf1f4c795edace88aa35fff3a

https://gist.github.com/mattsse/a2b6c5f894532815e8e5a210fe87ddd1

https://t.me/foundry_rs/8504

[mattsse]

yeah, seems like a good thing to have in ethers-solc, perhaps there is way to figure out what error codes are propagated to solc, will take another look at solidity codebase

[onbjerg]

Not sure if it's out of scope for this PR, but should we also have something like .sethrc (cast.toml?) to configure things like ETH_FROM etc. without having to explicitly state it every time? .sethrc example

[gakonst]

I'd pull all of these Configs in the Foundry.toml, instead of having many configs

[mattsse]

yeah we can support a [cast] section and a [foundry] where you'd set some meta config vals like color palette

[mattsse]

Update

• Simplified BuildArgs
• Added separate CLI arg types EvmArgs instead of using EvmOpts
  • All values in EvmArgs are optional so that they only override the config's values if they are present as CLI arguments. But all have a default in Config so we can always safely extract an EvmOpts
• integrated Figment/Config in the subcommand by implementing figment::Provider on the args
• More docs on how Figment and Config works
• more remapping support:
  • CLI > ENV > remappings.txt > autodetect
  • deviated from previous approach that merged all (Env + remappings.txt)

Todo

• additional tests to ensure values are set correctly

cc @gakonst

[mattsse]

blocked by gakonst/ethers-rs#810

added more integration tests and docs.

Behavior of remappings is currently different than on master: remappings are not extended but replaced as a whole:

Remappings are built in this order (last item takes precedence)

• Autogenerated remappings
• toml remappings
• remappings.txt
• Environment variables
• CLI parameters

[gakonst]

amazing