Please provide a cargo install option to not write .crates.toml

[joshtriplett]

When installing a crate as part of a package build process (with --root pointing to a directory that will get packaged as /usr), I'd like to avoid writing the .crates.toml file (which would become /usr/.crates.toml). Right now, I run cargo install and then remove that file afterward. Please consider providing an option to not write .crates.toml at all.

[alexcrichton]

Sounds like a good option to me!

[cardoe]

Yes 👍 on this as well. For Gentoo I have to remove .crates.toml after the fact as well. (ref for me gentoo/gentoo#2918)

[JustAPerson]

@alexcrichton
I was giving this a try since it looked relatively straight forward. Just a few quick questions.
I tried putting this block in an if statement after adding a --no-metadata flag. However, it looks like the file is implicitly created elsewhere when trying to acquire a file lock. Perhaps just deleting the file at the very end of the install() function would work best?

While I'm at it, does this look fine for the updated --help?

...
    -q, --quiet               Less output printed to stdout
    --color WHEN              Coloring: auto, always, never
    --frozen                  Require Cargo.lock and cache are up to date
    --locked                  Require Cargo.lock is up to date
    --no-metadata             Do not write the .crates.toml file in the root

That's what I wrote before discovering the implicit creation. Should I specify it could delete an existing .crates.toml or should we check for the existence of the file before acquiring a lock and then only deleting the file if we created it?

[alexcrichton]

@JustAPerson oh I think it's also ok to avoid the lock if --no-metadata is passed (avoiding the file being created at all) because in theory that's covered by whomever's calling Cargo at that point. Also yeah help looks good to me!

[ehuss]

The --no-track flag was added as part of the install-upgrade feature which implements this request. Closing this in favor of the tracking issue at #6797.