terminal autocomplete stuff..?

[Gankra]

Some terminals/clis have explicit support for tab-completion integration. Is that something cargo-dist can/should help with in some way? Generating it? Packaging it? Installing it?

Out of scope for MVP I think.

[Be-ing]

A more general way to frame this is "where to put generated artifacts". Unfortunately the design of Cargo makes this an awkward problem. Build scripts are only given the OUT_DIR environment variable to write generated files to, which contains a hash in its path that can't easily be calculated by external tools. This is fine for intermediate files used during the build process, but it makes it impractical for an external tool to do anything with a file generated by the build script. Ideally, this would have a solution in Cargo. I started a discussion about that a few months ago but it didn't go anywhere.

In the meantime, cargo-dist could set an environment variable when calling cargo build to tell build scripts where to output generated files meant to be distributed with the executable/library.

Adding a post-build script as proposed in #33 doesn't solve this because there would still need to be a way to tell that where to output generated files.

[DCNick3]

With clap compile-time shell completion generation seems to be handled by using clap_complete::generator::generate_to in build.rs and later making the packaging tool put it where it's needed.

lsd uses a special env variable to make the build.rs put it somewhere outside of OUT_DIR. Here's how it's used in a packaging script: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lsd-git#n29.

For cargo-dist this would need special care during the build & then teaching the installers to put stuff in proper directories for shells to pick it up (it can't do this, right?)

Another common approach is to provide some sort of "generate shell completion pls" subcommand in runtime, which is then invoked after the build: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mullvad-vpn-cli#n90.

I think this approach is simpler, as it needs just a single extension point from cargo-dist: run something after installation