Cargo's next few years

announcements
8

Aaturon's blog post is a good description: http://aturon.github.io/2018/04/05/workflows/

The gist is adding a [task] section to Cargo.toml with the same syntax as dependencies, and making a cargo task foo command, which finds and runs a foo binary from a task package. The crucial properties which make this different from Cargo subcommands is that tasks are local to a workspace, locked via a lockfile, and work out of the box (no need to add "run cargo install cargo-foo" to your project's readme). This unlocks the following use-cases:

  • writing a "small-scale" automation, which is typically written in bash, in Rust, such as it is cross-platform, has access to powerful libraries like serde, and has tests
  • easy distribution for framework-specific automation: diesel might have a diesel-tasks package which provides cargo task generate-migration
  • allow to bootstrap a truly generic build system (a-la make/gradle) from Cargo. Project like just or cargo-make exist, but the main problem with them is that using them is not reproducible: you need to add "run cargo install cargo-make" to the readme, and hope that future users will get a sufficiently compatible version. cargo task make will be more or less inflatable.

It sounds like it ties in with our focus on plugins?

Maybe? From the blog-post, I gathered that the main focus is on making writing custom Cargo sub commands easier, by expanding the public API Cargo offers. This seems pretty challenging to me, stability wise (see two awesome diagrams about plugins here). What personally would be more interested in is ability to run custom sub-commands as a part of reproducible build.

1 Like