mihai-dinculescu / cargo-wipe Goto Github PK

Just ran cargo wipe rust for a dry run. At the end, the message displayed reads Run cargo wipe target -w to wipe all folders found. USE WITH CAUTION!

I'm assuming it's supposed to recommend cargo wipe rust -w?

It sounds useful to have a flag that allows the exclusion of recently modified folders from the wipe (e.g. -d 30 will wipe everything that hasn't been touched in 30 days).

would be nice to do node and target dir at once.

It might be useful to offer an interactive mode so that the user can decide which folders to wipe on the fly.

It might be useful to have a flag that disables colours.

Currently one or more paths can be ignored by using the -i flag.

cargo wipe rust -i /home/user/path1 -i /home/user/path2

It would be most useful if these paths can be loaded from a file

cargo wipe rust -i /home/user/paths_to_ignore.txt

/home/user/paths_to_ignore.txt can contain one or more paths separated by new lines

/home/user/path1
/home/user/path2

This can be easily achieved by checking if the path given to the -i flag is a directory or a file.
If it's a directory, just ignore it. If it's a file, attempt to open it as text and parse the paths inside.

I am experimenting with rust and so do may users of this library. But is there any plans to move out cargo and go as separate install?

like brew for mac, choco for Windows ? I guess this utility can help and serve many developers around the spectrum.

PS: Full stack developer working with node can be benefited from if this is served without cargo. Again this is my personal two cents. I am OK with using it with cargo.

I was looking for something similar since ages. Thanks for great tool chain.

Running cargo wipe target -w removes the debug/release folders in target, but the rls folder (created by the Rust Language Server -- I use VS Code) is left untouched, so the target folder is not wiped in the end:

rust
├─ guessing_game
│  ├─ src
│  └─ target
│     └─ rls
│        └─ ...
└─ hello_cargo
   └─ src

Is this the intended behavior? Thank you!

As an additional safety check for node_modules you could check for the existence of package.json in the parent directory.

hey, I meet a proble, here is a directory vue-frontend, and when calling cargo wipe node in the directory

but when I call the find . type f | wc -l

the file_counts are not the same at all,

I have some function that modify from your code,

pub fn dir_size(path: impl Into<PathBuf>) -> io::Result<DirInfo> {
    let mut visited = HashSet::new();
    dir_size_0(path, &mut visited)
}

fn dir_size_0(path: impl Into<PathBuf>, visited: &mut HashSet<String>) -> io::Result<DirInfo> {
    let mut dir_info = DirInfo::new(0, 0, 0);

    let targetpath: PathBuf = path.into();
    for entry in WalkDir::new(&targetpath).max_depth(1) {
        let entry = entry?;
        let filepath = entry.path().display().to_string();

        if filepath == "." || filepath == "./" || filepath == targetpath.display().to_string() {
            continue;
        }

        if entry.file_type().is_dir() && !visited.contains(&filepath) {
            visited.insert(filepath.clone());
            let child_dir_info = dir_size_0(&filepath, visited)?;
            dir_info.dir_count += child_dir_info.dir_count + 1;
            dir_info.file_count += child_dir_info.file_count;
            dir_info.size += child_dir_info.size;
        } else {
            let file = File::open(&filepath)?;
            let metadata = file.metadata()?;
            dir_info.file_count += 1;
            dir_info.size += metadata.len() as usize;
        }
        
    }

    Ok(dir_info)
}

and the test resuls is

I am a little confused now, what is the matter with my code, or your code ?

Please consider adding a --dry-run flag that will find, list, summarize but not delete the target folders that will be deleted by cargo wipe if not run with the --dry-run flag.

The summary could include the number of files and size on disk that will be recovered.

ansi_term is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

E.g. cargo wipe -w -e Projects/bar/target would preserve the Projects/bar/target directory. This would allow me to run cargo-wipe in me projects directory but skip deletion of a small number of projects.

Re-architecting the current implementation to allow a more pluggable language listing could make for easier contributions.

Perhaps something like a list of defined regex matches for a Language option could allow for more language flexibility. This could be serializable and read from a config file, with a sane programmed default config file that is auto-generated.

use regex::Regex;
use serde::{Serialize, Deserialize};
use serde_regex; // Helper to serialize and deserialize RegEx

#[derive(Debug, Serialize, Deserialize)]
struct LanguageOption {
    /// The name of the language option. 
    option_name: String

    /// The RegEx that matches the target folder to be removed
    #[serde(with = "serde_regex")]
    target_folder_regexp: Regex,
    /// The optional RegEx that matches what the target folder must contain
    #[serde(with = "serde_regex")]
    target_folder_contains_regexp: Option<Regex>, //Maybe a list of Regex entries instead for multiple files
    /// The optional RegEx that matches what the target folder's parent must contain
    #[serde(with = "serde_regex")]
    parent_folder_contains_regexp: Option<Regex>, //Maybe a list of regex entries instead for multiple files
}

As seen above, adding serialization options for this allows these language options to be read from an external config (need appropriate serde_json or alike crate), which means users could add their own rules and options to this command.

Additionally, I imagined some additional struct fields for adding items that the target folder must contain, along with the parent folder. I think this might help alleviate #15

Example config:

[
  {
    "optionName": "MyWeirdEsotericLanguage",
    "targetFolderRegexp": "/someregex/",
    "targetFolderContainsRegexp": "/somefile/"
  }
]

or perhaps instead with multiple matches:

[
  {
    "optionName": "MyWeirdEsotericLanguage",
    "targetFolderRegexp": [
      "/someregex/",
      "/someotherregex/"
    ],
    "targetFolderContainsRegexp": [
      "/somefile/",
      "/someotherfile/"
    ]
  }
]

I think this would increase complexity about where to store the config and be cross platform (not sure if cross-platform is a goal currently), but would allow for that flexibility increase.

If I get some time, maybe I'll entertain a PR with an implementation of this :)

It might be useful to allow the use of multiple subcommands at the same time.

E.g.: "wipe both target and node_modules folders in the same run.

The target and node_modules aliases are more confusing than helpful. rust and node are enough imho.

We should get rid of the target and node_modules aliases in all the documentation. However, they should continue working for a few more versions so that we don't break existing commands that people might be usings.

I noticed on the TODO page that there are currently no plans to support the build systems of any other languages. Would pull requests adding additional support be accepted?

Currently, there is a slight inconsistency between the size shown by cargo-wipe and the real size shown on the disk. It would be lovely if we can fix this.