cargo-new: Custom Default Files

[danii]

Problem

Creating a new Rust project via cargo new (or cargo init) always produces the same, hard coded files, main.rs, or lib.rs. There's no way to add predefined code (for example, #![forbid(unsafe_code)] is an attribute many people religiously use, and could benefit from having it off the bat), or even change indentation (for example, using spaces at 2, tabs, etc).

Proposed Solution

I propose that 2 new configuration options (both being configurable from .cargo/config.toml, environment variables and command line flags): bin preset and lib preset. These two options would allow users to craft their own boiler plate to be used upon running cargo new.

Both options are paths. If cargo new is ran without --lib, the file pointed to by the bin preset path is copied to src/main.rs within the package. Otherwise, the file pointed to by the lib preset path is copied to src/lib.rs.

This concept can be expanded further; we can also specify that if the bin preset or lib preset path point to a directory, that the whole directory by copied to src. This enables us to create multi-file presets. I do not have a use case for this, but it is easily possible.

Proposed Command Line Flag

For the command line, rather than two flags, I propose one flag, `--preset` which takes a path. Two aren't necessary as only one can be used; `cargo new` only either creates a bin or a lib (`--lib`). The option overrides the environment variables and configuration file.

Proposed Environment Variables

Two environment variables will be used for presets; `CARGO_CARGO_NEW_BIN_PRESET` and `CARGO_CARGO_NEW_LIB_PRESET`. These options override the configuration file.

Proposed Configuration Keys

Two configuration keys will be used for presets; `cargo-new.bin-preset` and `cargo-new.lib-preset`.

Notes

I am personally willing to create a pull request to implement this.

I consider this a minor feature, but if needed I can start drafting an RFC.

[epage]

FYI we have #5151 for tracking package template support

[ehuss]

I'm going to close in favor of #5151 as I believe templates would cover this use case.