How do we balance reducing boilerplate in scripts while allowing reproducibility across systems

[epage]

• Examples:
  • Add "always there" dependencies (e.g. clap)
  • Keep major versions up to date (* means new scripts use latest but won't be able to run old scripts)
  • Avoid boilerplate of having to specify the current edition
• Ideas:
  • Default to loose, low-boilerplate approach (always latest edition, global prelude, global dependency-list) with warning telling people to run a command to turn it into a non-loose version (sets edition, embeds prelude and dependency list with a marker to say this is running in isolated mode)

[epage]

Other ideas

• Allow templates in and settings in .cargo so they can be defined in your workspace with your scripts (build on Define how this interacts with cargo config files #45)
• Allow specifying the template (Add ability to specify template to use in the script itself fornwall/rust-script#3)
• Implicit de-duplication with the workspace and/or a table in .cargo/config

Main risk for some of these is slowing down start up time

[bjorn3]

Another option would be to automatically copy the lockfile next to the script. For example for a foo.rs script it would generate a foo.rs.lock file. If one exists this file would be copied to Cargo.lock in the generated source dir and if cargo changed it, it would be copied back. You wouldn't strictly have everything in a single file anymore, but everything the user cares about would still be in a single file.

[epage]

Interesting idea

• We could possibly extend the format for edition so new scripts are locked in at the edition at the time of writing
• People might hate the clutter which might kill it
• I was also wondering about Share a lock file across scripts #48 to improve reuse of intermediate build results