Skip to content

Conversation

@weswc
Copy link
Member

@weswc weswc commented Jun 27, 2025

This PR contains 3 commands for cache. rv cache has the same behavior for consistency across versions

  1. rv cache dir - lists the cache directories same as rv cache does.
  2. rv cache purge - purge/remove entries from the cache. Has the following behaviors:
    a. No flags purges the entire cache
    b. --repositories - listed alias of repositories in config are removed
    c. --packages - package versions as resolved in the project are removed
  3. rv cache refresh - "refreshes" the repository databases for the listed repository aliases.

Additionally, all cache commands no longer require the resolution to be successful in order to perform action. Previously, resolution had to be completely successful to print cache directories, but this is not ideal as determining cache details may be needed/wanted in an unresolved status. Now, the resolution takes as much as is found, and then warns the user the action/info may not be complete due to the project being unresolvable.

Copy link
Member Author

@weswc weswc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also planning on including --binaries-only and --src-only` flags after this PR


removed.push(format!("{name} ({version}) - {}", types.join(" and ")))
}
PurgeDepResult::NotInCache { name, version } => not_removed.push(format!(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deps that are determined to be "NotInCache" are packages that would be in cache, but haven't been synced yet. I'm a bit unsure if I should list it as "removed" or "not removed". The pros/cons I see:

  • Removed - For the sake of the user, the package not being in the cache before the purge is the same result as if it was removed, so we should display it as such
  • Not Removed - Factual and communicates that if you're having issues with this package its not because of the cache

Ultimately, this scenario likely won't appear that often because if you're having issues with a package, its likely in the cache and you're going to target it specifically, but wanted to call it out.

}
}

impl fmt::Display for PurgeResults<'_> {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decided to leave paths out of the displayed results as it is not what a user would typically want, but recorded them and included as part of the json to leave them accessible if someone needs them.

#[derive(Debug, Subcommand)]
pub enum CacheSubcommand {
/// Shows the cache directories for each repository used by rv project
Dir,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure if we want an aliased subcommand for dir/info, that is the same as rv cache, or remove this and leave if no subcommand, just display as before. I see both ways, so will leave it to your judgement

}

#[derive(Debug, Subcommand)]
pub enum CacheSubcommand {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not attached to any of the subcommand names, so if you have different ideas I'm open. The basic things I wanted to include is:

  • A way to remove "things" from the cache, whether it be the entire cache, entire repositories, or packages
  • A way to update targeted repository databases instead the bulky way of using the env var to update all of them

@weswc weswc requested a review from Keats June 27, 2025 13:42
@dpastoor
Copy link
Member

dpastoor commented Jul 1, 2025

i think there is another permutation

b. --repositories - listed alias of repositories in config are removed

there are the repository-db's and then there are the packages in a given repository. I think those are two common scenarios to want to purge. Eg "I realized the packages from that repo i want to install differently" type deal. I'd suggest we have

rv cache purge --repository-dbs "prism" 
rv cache purge --repository-dbs "prism,ppm"

empty string = all?

same thing goes then having --repository="prism" = repositorydb + packages

@weswc
Copy link
Member Author

weswc commented Jul 1, 2025

Are you thinking including that in addition to refresh? I included refresh as the parallel to that, where imo, a naive user may not understand what a repository-db is, but saying you need to refresh your available packages may be clearer?

I'm okay either way, but I did consider the repo db aspect and chose, for a first pass, to keep it separate from purge

@dpastoor
Copy link
Member

dpastoor commented Jul 1, 2025

refresh i'm not sure the specific use case over purge + eg purge + summary etc. Eg what is the use case to just refresh then and there but never run another command?

from a repo-db perspective this just needs to be a concept that is explained when people are trying to determine what to purge. From my end, we have global purges - do everything associated with everything in the rproject - then more targetted purges, where targetting could be based on a repository in question, or a particular thing in the rproject - eg all repository databases.

Copy link
Collaborator

@Keats Keats left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like i forgot to publish my comments

name: &str,
version: &Version,
source: &Source,
) -> Result<(Option<PathBuf>, Option<PathBuf>), std::io::Error> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe return a struct so we don't guess which path is the source and which one is the binary?

/// Repositories are aliases corresponding to repos in the config
pub fn purge_cache<'a>(
context: &'a CliContext,
resolution: &'a Resolution<'a>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a resolution to purge things?


let mut dep_res = Vec::new();
for d in dependencies {
let res = if let Some(dep) = resolution.found.iter().find(|r| &r.name == d) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if people pass a dep name, don't they want to purge all the versions of that dep?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants