Accept stdin for `cargo update`

[asasine]

Problem

Hello! I'm writing a tool that updates the lock file for the set of git dependencies that all belong to a specific GitHub org. Rather than expect such a niche feature from Cargo itself, my plan was to use command chaining and cargo_metadata by filtering the resolved graph to the desired set and piping the package IDs into cargo update.

Proposed Solution

Add a feature to cargo update [spec...] such that spec... can be taken from stdin, allowing for chaining commands. Either spec... can be -, forcing stdin, or cargo update can default to stdin if spec... is empty and stdin is connected to a pipe.

Adding a --stdin flag would also be acceptable, leaving [spec...] untouched. The behavior would be the same (read [spec...] from stdin).

cargo update would read stdin until EOF then process it as if it were equivalent to [spec...]

Notes

One solution that depends on more shell-specific features is nesting commands e.g., in Bash:

cargo update $(filter-deps 'SomeGitHubOrg')

however, I believe this is less portable than the alternative of chaining commands:

filter-deps 'SomeGitHubOrg' | cargo update

as this can be done without a shell too (e.g., using std::process::Command).

[epage]

however, I believe this is less portable than the alternative of chaining commands:

I tend to script exclusively for bash. How much of a portability issue is this generally and for your specific application?

as this can be done without a shell too (e.g., using std::process::Command).

If you have access to std::process::Command, you can just as easily pass them through .arg. Granted, there might be other scenarios were the functionality is more limited.

One solution that depends on more shell-specific features is nesting commands e.g., in Bash:

Another option is xargs

filter-deps 'SomeGitHubOrg' | xargs cargo update

This doesn't require specific shell syntax support but does require the availability of that command.

[asasine]

The main portability issue with the above is that it depends on subshells, which Windows' cmd.exe/batch does not support without hackery like writing stdout to a file then executing that file. However, cmd.exe does support piping stdin to stdout with |, so filter-deps '...' | cargo update would work.

I'm not familiar with any xargs implementations available on Windows.