compile_config()中cfg其实是default_cfg ，在merge和compile的时候放到了usr_cfg的位置 about di-engine HOT 4 CLOSED

cfg就是user config啊，在任何compile和merge的时候都是放在第二个参数上

from di-engine.

create_config才是usr_config的哇。。？

from di-engine.

理一下config的结构和compile_config的原理:

• user_config：用户写的env_algo_config.py是user_config；user_config中有两部分，main_config和create_config，前者是具体的参数设置信息，后者是具体各个模块创建需要的信息（比如什么类型，相应文件的引用路径）。
• main_config(cfg)：main_config是所有使用情况下都必需的config，包含所有具体的配置信息，所以在代码里也一般简写为cfg
• create_config：对于使用CLI工具，或者serial_entry_xxx.py系列入口，为了实现多算法通用的接口，使用注册器-创建函数机制来创建模块，因此就需要指定额外的信息（比如policy要指定type是dqn），并在compile_config函数中传入create_config，同时指定auto=True；但是如果使用自定义入口（比如cartpole_dqn_main.py），就可以直接import相关类来创建对象，同时直接将具体的类名传入compile_config函数并指定auto=False
• compile_config：DI-engine中的诸多模块都有default_config，一方面在阅读代码时可以看到这个类最常用的配置参数值，另一方面，用户在使用时就不需要指定所有相关的配置字段了，只需指定其想修改的相关字段。而compile_config，就是将user_config和default_config进行合并和转化的相关函数，而要在这个函数中获得default_config，就必须知道这次启动想要使用的模块对应的类，所以要么传create_config，要么传具体的类名
• 另外，关于config的高级转化和验证，我们还设计实现了Loader相关工具，在分布式版本中将会起到重要作用，有兴趣的话可以了解一下 https://github.com/opendilab/DI-engine/tree/main/ding/utils/loader

from di-engine.

好的 懂了 多谢~~

from di-engine.