Go supports tracking dev CLI tools with IaC in go.mod, by running go get -tool <main module>. Users can then run go install tool to place the tracked tools into $GOBIN. As long as $GOBIN is in $PATH, then users can run the tools like any other program.

NPM supports tracking dev CLI tools with IaC in package.json, by running npm install <package> --save-dev. Users can then run npm install to download the tools into node_modules. Then users can run the tools with npx <tool>.

Python supports tracking dev CLI tools with IaC in requirements.txt. (Unfortunately, requirements{-_}.txt tends to break many security auditing systems.) Users can then run pip install -r requirements.txt to download the tools. Then users can run the tools like any other program.

I've been managing my Rust dev CLI tools with an install.mk file, using manual cargo install <tool>@<version> commands. But such manual scripts do add complexity.

make must be installed (I've worked in departments than ban make). makefiles require additional linting, and beg questions about POSIX vs GNU vs BSD implementations.

bash, sh, etc. suffer from portability for wholly native Windows developers, though improves ShellCheck lint-ability compared to make.

Ansible may or may not have mature cargo support. Anyway, that brings in Python, adding more complexity, attack surface, and so on.

Docker is nice as an option. But I don't like forcing developers to use Docker for all development needs.

Too many developers end up writing subtle quirks in all of these kinds of scripts, especially safety and portability breaking quirks.

Much prefer using Cargo.toml directly.

Can we get such a feature for cargo? It would encourage engineers to properly IaC more of their build environment, so that Rust projects in the wild are more likely to successfully compile when forked. It would also allow tools to participate in Cargo.lock, with the possibility of deeper pinning guarantees.

It would also provide a standard way for non-Rust users to pin tools that they happen to install via cargo. (Whether by choice, or by lack of an entry in OS package managers.)

In cargo I see dependencies, dev-dependencies, and build-dependencies, though those seem to be designed strictly for other purposes. A new key like tool-dependencies may help.

2 posts - 1 participant

Read full topic