CITA 的命令行工具（一）

随着时间的推移，cita-cli 这个项目进行了将近五个月了，项目的状态也由积极开发转入后期维护阶段，基本上来说，除非碰到一些特殊的问题，否则就功能上不会有太大的改动了，特殊的问题包括 Rust 出新功能、新版本，CITA 新版本适配等等。

起源

五个月之前，CITA 自带的查询命令是用 Python 脚本做了一个简单的封装，构造了一个 txtool 的目录，目录下面一堆脚本。就功能上来说，基本 RPC 接口都支持，并且处于可用状态，但是这些脚本存在一些让人非常难受的问题：

Python 脚本会将返回值、构造的交易 code 等东西存在文件里面，强依赖目录结构
Python 脚本依赖很多第三方库，并且有些库并不在 pip 仓库里面，这意味着，如果本机没有构造对应的环境，就强依赖 docker 环境
命令行参数没有补全，全靠手打或者复制黏贴
对用户（包括开发者）不友好

在某一日，我开发 debug 的时候，实在没法忍受这样的开发工具了，于是萌生了自己写一个对人（至少让我开发的时候舒服）友好的命令行工具的想法。在我最初的单纯想法里，这个工具必须有以下的功能：

必须让用户舒服、必须让用户舒服、必须让用户舒服
可以直接拿着 binary 运行，不依赖目录等神奇的东西
覆盖 RPC 接口

没错，最开始的时候，什么交互式命令行的想法是不存在的，最重要的是写出来给自己 debug 的时候稍微舒服一点，然后不要依赖一堆乱七八糟的东西。于是带着这个简单的想法，cita-cli 的开发工作正式在我个人仓库开始了开发。

开发过程

这个项目一定是基于 Rust 最新的 stable 版本进行开发的，所以，如果编译不过或者编译失败，很简单的两步操作：

$ rustup update stable
$ cargo update

如果还编译不过，检查自己的环境是否存在一些神奇的操作。

版本选择

为什么选择 stable 版本呢，这是一个习惯问题，对于 Rust nightly 的功能，虽然很吸引人，但是，并不是不能舍弃，所有 nightly 都是由 stable 开发而来。追 Rust 新功能的进度是每个 Rust 开发者都需要做的事情，每天看看 roadmap 的开发进度，有空帮忙测试一下最新的功能，这些都没什么问题。不过，从学习 Rust 以来，我都坚持自己真正要写的项目坚持 stable。

开发思路

客户端 API 的库之前有开发过，但命令行工具真的还没碰过，心里有点虚，于是我一遍开发 API 库，一遍在公司拉了个大佬来掌眼。可以在 Github 上看到这个项目的主力开发也就两个人，前期我主要还是在开发 API 库，真正的命令行样式还是大佬把关的。

整个 cita-cli 是分为两个库的：

cita-tool：API 库，用来支持 cita-cli ，里面就是与 CITA 交互需要的各种方法，就是 Rust 版的 SDK
cita-cli：这个才是真正的应用程序

项目从一开始就分成两个库进行开发，第一是为了让项目能同步进行，第二是为了方便其他人如果需要的话，可以直接引用 SDK 做自己的扩展。

到目前为止，两个库都经历过最少三次整体大重构，就是直接推翻重写的那种，理由不外乎下面几种：

发现更棒的写法
发现更好的思路
加新功能时扩展性太差，直接删了重写

目前的实现里面，其实还有一些不是特别满意的方面，凑合能用罢了。

我们都是实验品

诚实地说，其实我们都在用一个实验品，在这个库里面，我实验了各种实现思路:

我用 tokio 和 hyper 做了各种实现的写法（下一篇详细讲），思路从写客户端的完全同步到符合 Future 完全异步，最后到现在的实现思路
交互式界面框架我们做过一些对用户没有感知的神奇测试（下下篇详细讲）
Rust 过程宏、trait + 泛型、build.rs，各种新库的引入

虽然我们保证 master 分支编译是没有问题的，但是开发中，我们会作死地使用各种神奇的东西做实验，这些实验在 cita-cli 上实现没有问题之后，同样会影响到 CITA 内部的开发思路，至少对于我开发的部分是这样的（比如最近我又把 cita-network 重构了）。

对于命令行接口，其实我是不保证完全兼容之前的实现的，如果我或者别人提的意见经过考虑后发现确实语义更清晰，那么随时会改，修改的底气在于交互式界面的自动补全命令功能，命令行没有补全，真的是太难受了。

秉承的思路最重要的是让用户舒服，为了舒服可以做任何修改。

预期完成了吗？

相对于刚开始的预期，可以说这个项目是成功的完成了。但是在开发过程中的畅想思路还有很多是没有完成的，一些比较大的 feature 已经处于无限延期状态，一些相对较小的 feature 以后如果有时间，可以考虑进行开发，但是近期是不可能了。

整体来说，项目比较成功，虽然没有到达完美的阶段，但是目前可用性还不错，总算是倒逼 txtool 退出历史舞台。

小结

这篇博客算是官宣吧，cita-cli 正式进入后期维护阶段，不再进行频繁的功能性更新开发，如果有朋友觉得有更好的思路欢迎提 Issue 或者 PR。不过呢，实验性质的开发依然会尝试在这个库里折腾（比如近期的 2018 edition 更新）。

之后两篇博客，分别介绍 cita-tool 和 cita-cli 两个库开发中的踩坑、选择的一些思路。