Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo vendor should have a separate option to choose where to output the .cargo/config #7280

Open
glandium opened this issue Aug 22, 2019 · 4 comments
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-vendor S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@glandium
Copy link
Contributor

Currently, the choice is between:

cargo vendor path

printing out

Downloading crate
...
Vendoring crate ...
To use vendored sources, add this to your .cargo/config for this project:

[source.crates-io]
replace-with = "vendored-sources"

...

and

cargo vendor --quiet path

which outputs... nothing. At all.

There should be a way to reliably get that .cargo/config snippet somehow.

@glandium glandium added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Aug 22, 2019
@weihanglo
Copy link
Member

weihanglo commented Oct 28, 2023

The configuration is printed to stdout, and stderr for other messages. It should just work if you can redirect your stdout to a file. For example,

$ mkdir .cargo
$ cargo vendor my-vendored-sources >> .cargo/config.toml

There are some explanation about cargo printing out the needed configuration in the doc of cargo vendor, though it doesn't mention it print to stdout. I would recommend

  • Add one or two lines explanation to the doc about the final configuration is printed to stdout.
  • At the bottom of cargo vendor doc, add an example of how to redirection configuration to .cargo/config.toml file.

@weihanglo weihanglo added A-documenting-cargo-itself Area: Cargo's documentation S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review E-easy Experience: Easy labels Oct 28, 2023
@panekj
Copy link

panekj commented Oct 28, 2023

It does work as you describe, but the reason why I dislike that (and why I opened the PR) is that it is not clear from the CLI interface itself:
a) what will happen after cargo vendor
b) if the config present by cargo vendor can be safely redirected to file

When I'm inside terminal, I shouldn't need to read external documentation or a manpage to know such crucial piece of information.
Additionally, if the config file is written I don't have to worry about output interface and whether it will ever change.

@weihanglo
Copy link
Member

…it is not clear from the CLI interface itself:
a) what will happen after cargo vendor
b) if the config present by cargo vendor can be safely redirected to file

Thanks for the reply! You describe the issue pretty much the same as what I've seen. This does sound like an issue of lacking of documentation. A clear CLI help would definitely help people understand how to use cargo vendor.

One thing worth noting is Cargo has one short help text (via cargo vendor --help) and the other long help text (via cargo help vendor), which by using the latter you can stay in terminal and read it.

Additionally, if the config file is written I don't have to worry about output interface and whether it will ever change.

I don't quite get this. This doesn't resolve the aforementioned issue — lack of documentation. People still need to read into the doc to figure out where cargo vendor writes to. People can also have cargo vendor > my-config.toml if they feel unsafe to redirect to .cargo/config.toml.

@weihanglo
Copy link
Member

weihanglo commented Oct 29, 2023

Just realized the original issue is that --quiet makes stdout "really quiet":

if config.shell().verbosity() != Verbosity::Quiet {
if vendor_config.source.is_empty() {
crate::drop_eprintln!(config, "There is no dependency to vendor in this project.");
} else {
crate::drop_eprint!(
config,
"To use vendored sources, add this to your .cargo/config.toml for this project:\n\n"
);
crate::drop_print!(
config,
"{}",
&toml::to_string_pretty(&vendor_config).unwrap()
);
}
}

I can think of two options to solve this:

  • Don't quiet stdout for cargo vendor for the final configuration.
  • Have the other option, such like -w or -o to control where the necessary config will be printed to.

For this part of design, it is not accepted so I'll take down the labels.

@weihanglo weihanglo added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review labels Oct 29, 2023
@epage epage removed the E-easy Experience: Easy label Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-vendor S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

5 participants