refactor: centralize git checkouts and db paths #13187
Conversation
|
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
A-configuration
| /// Gets the directory of code sources Cargo checkouts from Git bare repos | ||
| /// (`<cargo_home>/git/checkouts`). | ||
| pub fn git_checkouts_path(&self) -> Filesystem { | ||
| self.git_path().join("checkouts") | ||
| } | ||
|
|
||
| /// Gets the directory for all Git bare repos Cargo clones | ||
| /// (`<cargo_home>/git/db`). | ||
| pub fn git_db_path(&self) -> Filesystem { | ||
| self.git_path().join("db") | ||
| } |
There was a problem hiding this comment.
How appropriate is it to join on a Filesystem and pass that around?
From what little I've interacted with Filesystem, it seems like its meant to be the root for (e.g. its whats lockable) which makes it feel strange to creating Filesystems for directories we don't lock (instead we lock the parent)
There was a problem hiding this comment.
I see it like “hey this path might be locked so be careful when manipulate stuff under the path.” registry_index_path is constructed in the same way, though this doesn't justify it is correct.
There was a problem hiding this comment.
Yea, the idea is to only interact with the filesystem using Filesystem, and never use raw Path. That helps ensure you only access files with appropriate locking. Unfortunately we're not very good with that. Whenever into_path_unlocked is used, that indicates the abstraction is leaking. It is necessary in many cases, since other libraries (like libgit2) won't take a Filesystem, but I thinkinto_path_unlocked is used a little too often. There are also many places that don't use Filesystem. For example, Layout has its own locking mechanism, and thus doesn't need it.
There was a problem hiding this comment.
Which lock is being held for git checkouts and git dbs?
If its not the individual db's and checkouts, then this seems like the wrong API in the first place as we are saying "this is lockable" when, in reality, locking it would be the wrong decision. One idea for improving this (if that is the case) is to "lock project" and allow Filesystem.join to carry-forward the path to the lockable resource.
|
Thanks! @bors r+ |
bors
added
S-waiting-on-bors
refactor: centralize git checkouts and db paths
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Rust version was updated to 1.77 hours ago rust-lang/rust#119181. I'll bump the version of Cargo today. |
|
Blocked on #13192 |
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 10 commits in 1a2666ddd14cf0a255d4ddb61c63531c259a7b39..363a2d11320faf531f6aacd1ea067c6bc08343b9 2023-12-17 17:53:53 +0000 to 2023-12-22 03:12:42 +0000 - refactor: centralize git checkouts and db paths (rust-lang/cargo#13187) - Bump to 0.78.0; update changelog (rust-lang/cargo#13192) - refactor: custom error types for `cargo-util-schemas` (rust-lang/cargo#13186) - chore(deps): update rust crate handlebars to `v4.5.0` (rust-lang/cargo#13168) - Hold the mutate exclusive lock when vendoring (rust-lang/cargo#12509) - refactor: clean up package metadata (rust-lang/cargo#13184) - ci: check SemVer for cargo-util-schemas on CI (rust-lang/cargo#13185) - refactor(schemas): Pull out as `cargo-util-schemas` (rust-lang/cargo#13178) - chore(rustfix): rename Readme.md to README.md (rust-lang/cargo#13181) - chore(rustfix): remove useless clippy rules and fix a typo (rust-lang/cargo#13182) r? ghost
What does this PR try to resolve?
This moves the logic of getting
$CARGO_HOME/git/checkoutsand$CARGO_HOME/.cargo/git/dbto a central place.How should we test and review this PR?
There is no functional change.
Additional information