entrypoint

使用这个有观点的应用框架/包装器消除主函数的样板代码

关于

entrypoint 的设计目标如下

• 消除应用启动/配置的样板代码
• 帮助强制执行应用最佳实践

这个 crate 实际上做什么？

entrypoint 将用户定义的函数包装起来，自动配置/设置/处理以下内容

• 简单的应用程序错误处理（通过 anyhow）
• 命令行参数解析（通过 clap）
• .dotenv 文件处理和环境变量填充/覆盖（通过 dotenvy）
• 日志记录（通过 tracing）

用户定义的函数旨在替换 main()。

这意味着这个主/入口点函数可以编写得好像所有配置/处理/样板代码都准备好了。更具体地说

• anyhow 可用并可使用
• clap::Parser 结构已被解析并填充
• .dotenv 文件已被解析；环境变量已准备好
• tracing 已配置，全局订阅者已注册

开发者的话

entrypoint 与部署我的第一个 crate 一样重要。

事实证明，它并不真的那么有用。我有点认为，最好还是在你的应用中明确设置这些内容。这样做不值得。

不太可能进一步开发。

使用

默认配置

1. 包含 entrypoint 预言

   use entrypoint::prelude::*;
   

2. 定义一个 clap 结构和 derive 默认入口点特质实现

   #[derive(clap::Parser, DotEnvDefault, LoggerDefault, Debug)]
   #[log_format(full)]
   #[log_level(entrypoint::tracing::Level::INFO)]
   #[command(version, about, long_about = None)]
   struct CLIArgs {
       #[arg(short, long, env)]
       cli_arg: bool,
   }
   

3. 定义一个入口点/main 函数

   #[entrypoint::entrypoint]
   fn entrypoint(args: CLIArgs) -> entrypoint::anyhow::Result<()> {
       // args are parsed and ready to use
       info!("cli_arg set to: {:?}", args.cli_arg);
   
       // env::vars() already loaded-from/merged-with .dotenv file(s)
       let _my_var = env::vars("SOMETHING_FROM_DOTENV_FILE");
   
       // logging is ready to use
       info!("entrypoint::entrypoint");
   
       Ok(())
   }
   

自定义配置

使用默认行为是完全合理的，但覆盖一些默认实现可以提供定制化。

使用说明

1. entrypoint函数必须
   1. 有一个clap::Parser输入参数
   2. 返回entrypoint::anyhow::Result<()>
2. 当与其它属性宏（例如[tokio::main]）一起使用时，#[entrypoint::entrypoint]的顺序可能很重要。