fix(embedded): Don't pollute script dir with lockfile #12284
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This puts the lockfile back into a target directory in the users home, like before rust-lang#12268. Another idea that came up was to move the workspace root to be in the target directory (which would effectively be like pre-rust-lang#12268) but I think that is a bit hacky / misleading. This does mean that the lockfile is buried away from the user and they can't pass it along with their script. In most cases I've dealt with, this would be fine. When the lockfile is needed, they will also most likely have a workspace, so it shoud have a local lockfile in that case. The inbetween case is something that needs further evaluation for whether we should handle it and how.
|
r? @weihanglo (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
A-lockfile
33 tasks
weihanglo
reviewed
Jun 19, 2023
There was a problem hiding this comment.
Looks good.
Just this line ws.root() needs to be replaced with lock_root.
cargo/src/cargo/ops/lockfile.rs
Line 90 in 5191f15
|
Thanks for catching that! I've pushed a fix |
weihanglo
approved these changes
Jun 19, 2023
|
@bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 20, 2023
Update cargo 12 commits in 0c14026aa84ee2ec4c67460c0a18abc8519ca6b2..dead4b8740c4b6a8ed5211e37c99cf81d01c3b1c 2023-06-14 18:43:05 +0000 to 2023-06-20 20:07:17 +0000 - Convert valid feature name warning to an error. (rust-lang/cargo#12291) - fix(embedded): Don't pollute script dir with lockfile (rust-lang/cargo#12284) - fix: remove `-Zjobserver-per-rustc` again (rust-lang/cargo#12285) - docs: some tweaks around `cargo test` (rust-lang/cargo#12288) - Enable `doctest-in-workspace` by default (rust-lang/cargo#12221) - fix(embedded): Don't auto-discover build.rs files (rust-lang/cargo#12283) - fix(embeded): Don't pollute the scripts dir with `target/` (rust-lang/cargo#12282) - feat: prepare for the next lockfile bump (rust-lang/cargo#12279) - fix(embedded): Don't create an intermediate manifest (rust-lang/cargo#12268) - refactor(embedded): Switch to `syn` for parsing doc comments (rust-lang/cargo#12258) - fix(embedded): Align package name sanitization with cargo-new (rust-lang/cargo#12255) - Clarify the default behavior of cargo-install. (rust-lang/cargo#12276) r? `@ghost`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
This puts the lockfile back into a target directory in the users home,
like before #12268.
Another idea that came up was to move the workspace root to be in the
target directory (which would effectively be like pre-#12268) but I
think that is a bit hacky / misleading.
This does mean that the lockfile is buried away from the user and they
can't pass it along with their script. In most cases I've dealt with,
this would be fine. When the lockfile is needed, they will also most
likely have a workspace, so it shoud have a local lockfile in that case.
The inbetween case is something that needs further evaluation for
whether we should handle it and how.
How should we test and review this PR?
Its a bit difficult to test for the lockfile in the new location, so this is mostly being tested in that the lockfile no longer exists next to the script.