Change config paths to only check CARGO_HOME for cargo-script#14749
Change config paths to only check CARGO_HOME for cargo-script#14749bors merged 1 commit intorust-lang:masterfrom
Conversation
|
@epage Even I found the code and changed it. But I am a little confused about your comments.
What do you mean by downloading a script? And what kind of spurious files might end up being created? I thought it only read the config files. |
If I download a script off the internet, my browser will put it in |
c00c27a to
cbb9dae
Compare
0xPoe
left a comment
There was a problem hiding this comment.
🔢 Self-check (PR reviewed by myself and ready for feedback.)
cbb9dae to
a61d845
Compare
a2d6143 to
09faa3e
Compare
Signed-off-by: Rustin170506 <29879298+Rustin170506@users.noreply.github.com>
09faa3e to
bd47da1
Compare
0xPoe
left a comment
There was a problem hiding this comment.
🔢 Self-check (PR reviewed by myself and ready for feedback.)
|
@bors r+ |
|
☀️ Test successful - checks-actions |
|
Thanks for your review! 💚 💙 💜 💛 ❤️ |
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
This was the original behavior. There was some concern over this previously and we switched to only loading config from CARGO_HOME in rust-lang#14749. After discussing this in today's cargo team meeting, we decided to switch it back. A concern brought up previously was if you previously downloaded a config and now download and run a script, you could get surprising behavior, maybe even dangerous. This does require some extra hoops because you don't have a `.cargo.toml` but a `.cargo/config.toml`. You can't directly download that but must first download a zip file and then decompress it without it having a parent directory. Contrast that with users who have a script in their repo and config that should apply to it. This is an important use case but one we will get less feedback on during calls for testing. In discussing this, we felt there are different use cases: - The repo with a config file - People surprised at how config loading works We settled on this change because it is consistent with the current behavior, even if it can be confusing and undesirable. We can then work to improve the overall config search path experience and both regular cargo commands and running of cargo scripts would benefit. This reverts commit bd47da1.
This was the original behavior. There was some concern over this previously and we switched to only loading config from CARGO_HOME in rust-lang#14749. After discussing this in today's cargo team meeting, we decided to switch it back. A concern brought up previously was if you previously downloaded a config and now download and run a script, you could get surprising behavior, maybe even dangerous. This does require some extra hoops because you don't have a `.cargo.toml` but a `.cargo/config.toml`. You can't directly download that but must first download a zip file and then decompress it without it having a parent directory. Contrast that with users who have a script in their repo and config that should apply to it. This is an important use case but one we will get less feedback on during calls for testing. In discussing this, we felt there are different use cases: - The repo with a config file - People surprised at how config loading works We settled on this change because it is consistent with the current behavior, even if it can be confusing and undesirable. We can then work to improve the overall config search path experience and both regular cargo commands and running of cargo scripts would benefit. This reverts commit bd47da1.
This was the original behavior. There was some concern over this previously and we switched to only loading config from CARGO_HOME in rust-lang#14749. After discussing this in today's cargo team meeting, we decided to switch it back. A concern brought up previously was if you previously downloaded a config and now download and run a script, you could get surprising behavior, maybe even dangerous. This does require some extra hoops because you don't have a `.cargo.toml` but a `.cargo/config.toml`. You can't directly download that but must first download a zip file and then decompress it without it having a parent directory. Contrast that with users who have a script in their repo and config that should apply to it. This is an important use case but one we will get less feedback on during calls for testing. In discussing this, we felt there are different use cases: - The repo with a config file - People surprised at how config loading works We settled on this change because it is consistent with the current behavior, even if it can be confusing and undesirable. We can then work to improve the overall config search path experience and both regular cargo commands and running of cargo scripts would benefit. This reverts commit bd47da1.
This was the original behavior. There was some concern over this previously and we switched to only loading config from CARGO_HOME in rust-lang#14749. After discussing this in today's cargo team meeting, we decided to switch it back. A concern brought up previously was if you previously downloaded a config and now download and run a script, you could get surprising behavior, maybe even dangerous. This does require some extra hoops because you don't have a `.cargo.toml` but a `.cargo/config.toml`. You can't directly download that but must first download a zip file and then decompress it without it having a parent directory. Contrast that with users who have a script in their repo and config that should apply to it. This is an important use case but one we will get less feedback on during calls for testing. In discussing this, we felt there are different use cases: - The repo with a config file - People surprised at how config loading works We settled on this change because it is consistent with the current behavior, even if it can be confusing and undesirable. We can then work to improve the overall config search path experience and both regular cargo commands and running of cargo scripts would benefit. This reverts commit bd47da1.
### What does this PR try to resolve? This was the original behavior. There was some concern over this previously and we switched to only loading config from CARGO_HOME in #14749. After discussing this in today's cargo team meeting, we decided to switch it back. A concern brought up previously was if you previously downloaded a config and now download and run a script, you could get surprising behavior, maybe even dangerous. This does require some extra hoops because you don't have a `.cargo.toml` but a `.cargo/config.toml`. You can't directly download that but must first download a zip file and then decompress it without it having a parent directory. Contrast that with users who have a script in their repo and config that should apply to it. This is an important use case but one we will get less feedback on during calls for testing. In discussing this, we felt there are different use cases: - The repo with a config file - People surprised at how config loading works We settled on this change because it is consistent with the current behavior, even if it can be confusing and undesirable. We can then work to improve the overall config search path experience and both regular cargo commands and running of cargo scripts would benefit. ### How to test and review this PR? This reverts commit bd47da1.
What does this PR try to resolve?
ref #12207 (comment)
After this change, we will only check the configs from the
CARGO_HOME.How should we test and review this PR?
The test has been updated.
Additional information
r? @epage