а зачем вам инвертирвоать зависимости конфигурации? у вас из этого и вылазят проблемы

потому что внезапно Server и узнаёт о том, что есть какой то vm config

Сейчас Server ничего не знает про VmConfig, тк я этого и добивался

NewServerConfig(work_dir) { NewUnionConfig(work_dir) { NewVMConfig(work_dir) {work_dir}, NewDHTConfig(work_dir) {work_dir} }

ошибся. там никто линию зависимостей не пересекает. Там вот так:

ServerConfig => Union::new(server.a, server.b, server.c) => ( union.vm_config(), union.dht_config() )

а зачем UnionConfig знать о ServerConfig?

у вас получается, что нижелажащая абстракция знает реализацию вышестоящей
и если вы вносите изменения в Server, то они потенциально затрагивают и слой Union (а может и глубже)

Нельзя ли наделать трейтов для каждого типа конфига c геттерами и в конструкторах требовать VmConfig: VmConfigProvider, и потом их все для одного большого типа конфига реализовать? То есть по факту у вас везде будет передаваться весь конфиг, но доступ будет только к отдельным сосотавляющим через геттеры?

много работы непонятно ради чего)

Нет, так еще больше кода выйдет

плюс так как компоненты хочется видеть независимыми, придется иметь несколько реализаций трейта: 1) для главного конфига 2) для component-only конфига

так вам по-факту component-only конфиг как отдельный тип и не нужен становится, вы все из главного вытягиваете там где это надо. То есть либо всегда работаете с конфигом через трэйт либо вытягиваете через этот трэйт составляющие конфига и создаете из них нужный тип, про трэйт забываете

Нужен :) Для тестов, и для реюза компонент

struct ServerConfig {
    key_pair: Keypair,
    base_dir: PathBuf,
    envs: Vec<String>,
}

trait DHTConfig {
    fn peer_id(&self) -> PeerId;
    fn work_dir(&self) -> PathBuf;
}

trait VMConfig {
    fn envs(&self) -> Vec<String>;
    fn work_dir(&self) -> PathBuf;
}

impl DHTConfig for ServerConfig {
         fn peer_id(&self) -> PeerId { key_pair.public().to_peer_id }
         fn work_dir(&self) -> PathBuf { base_dir.join("something") }
}

вот примерно такое я предлагаю
вам для реюза компонент либо придется писать новую конвертацию из нового конфига, либо реализацию трейта для этого нового конфига

Ага, я понял идею, спасибо! Но мне кажется это всё-таки оверкилл, плюс всё оказывается завязано на ServerConfig. А про него хорошо бы забывать как только покидаешь уровень Server-а

дак вы и забудете, ниже у вас только trait bounds останутся типа

Плюс появляются impl DhtConfig вместо DhtConfig

можно проще fn new(config: impl DhtConfig)

тем более