Hi.

When I use kondo in my directory project, it deletes all the build artifacts in all directories. Including the active one. woubuc/sweep: Reduce the disk usage of your projects by removing dependencies & builds on the other hand, only delete inactive directory: old projects that haven't been changed in more than a month.

Sweep (swp) finds old projects that haven't been changed in more than a month.

I thought I was missing some options. But I don't find any clue with kondo --help.

OS: Linux Kubuntu 18.04 Kernel: 4.15.0-128-generic AppVersion: 0.1.0 (the last from Cargo)

Terminal output (verbose):

popov@popov ~> env RUST_BACKTRACE=1 RUST_BACKTRACE=full /home/popov/.cargo/bin/kondo-ui
DEBUG [druid::localization] available locales [], current en-US
DEBUG [druid::localization] resolved: [en-US]
WARN  [druid::menu] MenuDesc::platform_default is not implemented for this platform.
INFO  [druid_shell::platform::gtk::application] gtk: Activated application
thread 'main' panicked at 'already borrowed: BorrowMutError', /home/popov/.cargo/registry/src/github.com-1ecc6299db9ec823/druid-shell-0.5.0/src/platform/gtk/window.rs:345:22
stack backtrace:
   0:     0x558f6fa08355 - std::backtrace_rs::backtrace::libunwind::trace::h577ea05e9ca4629a
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
   1:     0x558f6fa08355 - std::backtrace_rs::backtrace::trace_unsynchronized::h50b9b72b84c7dd56
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/../../backtrace/src/backtrace/mod.rs:66
   2:     0x558f6fa08355 - std::sys_common::backtrace::_print_fmt::h6541cf9823837fac
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:79
   3:     0x558f6fa08355 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf64fbff071026df5
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:58
   4:     0x558f6f9cfe9c - core::fmt::write::h9ddafa4860d8adff
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/fmt/mod.rs:1082
   5:     0x558f6fa079b6 - std::io::Write::write_fmt::h1d2ee292d2b65481
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/io/mod.rs:1514
   6:     0x558f6fa07340 - std::sys_common::backtrace::_print::ha25f9ff5080d886d
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:61
   7:     0x558f6fa07340 - std::sys_common::backtrace::print::h213e8aa8dc5405c0
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:48
   8:     0x558f6fa07340 - std::panicking::default_hook::{{closure}}::h6482fae49ef9d963
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:200
   9:     0x558f6fa06a53 - std::panicking::default_hook::he30ad7589e0970f9
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:219
  10:     0x558f6fa06a53 - std::panicking::rust_panic_with_hook::haa1ed36ada4ffb03
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:569
  11:     0x558f6fa066f8 - std::panicking::begin_panic_handler::{{closure}}::h7001af1bb21aeaeb
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:476
  12:     0x558f6fa066c4 - std::sys_common::backtrace::__rust_end_short_backtrace::h39910f557f5f2367
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153
  13:     0x558f6fa0667d - rust_begin_unwind
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
  14:     0x558f6f9ce240 - core::panicking::panic_fmt::h4e2659771ebc78eb
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
  15:     0x558f6f9d1082 - core::option::expect_none_failed::h448b58a024c2c33a
                               at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
  16:     0x558f6f9e8253 - core::cell::RefCell<T>::borrow_mut::h3603befb390e1563
  17:     0x558f6f9e97b1 - <O as gtk::auto::widget::WidgetExt>::connect_leave_notify_event::leave_notify_event_trampoline::h75875ed0bb521cbe
  18:     0x7f6e198508f7 - <unknown>
  19:     0x7f6e18a29346 - <unknown>
  20:     0x7f6e18a443cd - g_signal_emit_valist
  21:     0x7f6e18a4512f - g_signal_emit
  22:     0x7f6e19998534 - <unknown>
  23:     0x7f6e1999883d - <unknown>
  24:     0x7f6e1999e707 - <unknown>
  25:     0x7f6e1984da30 - <unknown>
  26:     0x7f6e1984dd30 - <unknown>
  27:     0x7f6e1973f3d0 - <unknown>
  28:     0x7f6e1984dc01 - <unknown>
  29:     0x7f6e199ad4c9 - <unknown>
  30:     0x7f6e1984dc01 - <unknown>
  31:     0x7f6e1984dea7 - <unknown>
  32:     0x7f6e18a2910d - g_closure_invoke
  33:     0x7f6e18a3c12e - <unknown>
  34:     0x7f6e18a44715 - g_signal_emit_valist
  35:     0x7f6e18a4512f - g_signal_emit
  36:     0x7f6e199a10c6 - gtk_widget_show
  37:     0x7f6e19879e20 - gtk_native_dialog_show
  38:     0x7f6e1987a5fa - gtk_native_dialog_run
  39:     0x558f6f9ebd6f - druid_shell::platform::gtk::window::WindowHandle::file_dialog::h61890d67b1dfd6d5
  40:     0x558f6f9ba465 - druid::win_handler::AppState<T>::handle_cmd::hc2abc37aad9a458d
  41:     0x558f6f9bab2f - druid::win_handler::AppState<T>::process_commands::h088db73c09277ecc
  42:     0x558f6f9baa1e - druid::win_handler::AppState<T>::do_window_event::h72282a694bc2956c
  43:     0x558f6f9c5125 - <druid::win_handler::DruidHandler<T> as druid_shell::window::WinHandler>::mouse_up::h6dea4b8b5390d8cc
  44:     0x558f6f9e9a31 - <O as gtk::auto::widget::WidgetExt>::connect_button_release_event::button_release_event_trampoline::h50bb8aa8b40ec165
  45:     0x7f6e198507fb - <unknown>
  46:     0x7f6e18a2910d - g_closure_invoke
  47:     0x7f6e18a3c05e - <unknown>
  48:     0x7f6e18a440af - g_signal_emit_valist
  49:     0x7f6e18a4512f - g_signal_emit
  50:     0x7f6e19998534 - <unknown>
  51:     0x7f6e1984d86e - <unknown>
  52:     0x7f6e1984f948 - gtk_main_do_event
  53:     0x7f6e19360765 - <unknown>
  54:     0x7f6e19390f92 - <unknown>
  55:     0x7f6e1874e417 - g_main_context_dispatch
  56:     0x7f6e1874e650 - <unknown>
  57:     0x7f6e1874e6dc - g_main_context_iteration
  58:     0x7f6e18d0fefd - g_application_run
  59:     0x558f6f9cb2d0 - kondo_ui::main::h725d4d5bbde190fc
  60:     0x558f6f9b314c - std::sys_common::backtrace::__rust_begin_short_backtrace::h4fefc5af64538c72
  61:     0x558f6f9cca0b - main
  62:     0x7f6e17aefbf7 - __libc_start_main
  63:     0x558f6f9ad3ea - _start
  64:                0x0 - <unknown>

Here's some weird thing I do: I have a directory outside home where I put my target, node_modules etc, and I put symlinks on the project dirs. Those "shadow" directories are arranged in the same directory tree as the home directory. When I delete such build artifacts, I don't delete the directory that contains it (so I do not break the symlink). I do this to keep backups small.

I think your tool can help automate this workflow. I could pass a directory to it and it would move build dirs and set up symlinks. I may send a PR if you wish.

Anyway, thanks for this tool!

I tried kondo in my home directory, and it ended up scanning everything due to a symlink:

'Steam/steamapps/common/Proton 7.0/dist/share/default_pfx/dosdevices/z:' -> /

It was taking a really long time, so I ran strace and found that it was lost somewhere in .../z:/proc. I know there are symlink loops in procfs, and I think walkdir is supposed to detect loops, so maybe it would have figured that out eventually. Still, I don't think it's a good default to follow links, and other tools I know like fd-find and dua-cli do not.

Semi-related, you might also want an option for same_file_system, but that's less clear as a default.

Details here from Apple's crash reporter tool: https://gist.github.com/atroche/12272ee32ac71ff20fed9bcf2226ab46

It wasn't in response to anything I did in the UI btw -- it seemed to happen while I was in another window.

Thanks for making this :) You freed up a bunch of space on my machine.

Kondo-ui doesn't seem to be published yet. At least cargo install kondo-ui fails. I can't find a way starting kondo-ui without downloading the binary directly or building it myself. Could you publish kondo-ui to crates.io so installing via cargo is straight forward?

Closes #64

Option older was implemented so that only projects that are older than the set value are looked over for cleaning.

PS: I'm still new to Open Source, if I did anything wrong please let me know!

Hi!

At the moment kondo crashes if it hits something it can't open. Maybe show some warning that folder/file x can not be analyzed and continue scanning.

I use version 0.2; build from git hash c2307fa0670baebdec9acf613385714cfc0ec052.

$ kondo -V
kondo 0.2.0

$ RUST_BACKTRACE=1 kondo
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/libcore/result.rs:1188:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:471
  11: rust_begin_unwind
             at src/libstd/panicking.rs:375
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:84
  13: core::result::unwrap_failed
             at src/libcore/result.rs:1188
  14: kondo::check_file_exists
  15: <core::iter::adapters::FilterMap<I,F> as core::iter::traits::iterator::Iterator>::next
  16: <core::iter::adapters::flatten::FlatMap<I,U,F> as core::iter::traits::iterator::Iterator>::next
  17: kondo::main
  18: std::rt::lang_start::{{closure}}
  19: main
  20: __libc_start_main
  21: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Hi, this is a question more than an issue. Sorry if this is not the right place for this.

I was wondering if there is an option to run kondo in non-interactive and maybe quiet mode? Something like kondo -a ~/code to remove all artifacts in one command without manual input.

Thanks for all the work put into this helpful tool!

Virtual environments are often named .venv. For example, this is the name used by Poetry when creating the venv inside the project folder. They are also often named venv, though maybe sometimes such a directory could contain things the user wants to keep (never met this, but who knows). I guess the leading dot of .venv makes it safer to assume this is a virtualenv and that it can be removed.

Links:

• https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv
• https://python-poetry.org/docs/configuration/#virtualenvsin-project
• https://discuss.python.org/t/trying-to-come-up-with-a-default-directory-name-for-virtual-environments/3750

Additionally, PEP582, which is used by some projects managers like PDM, says Python packages can be installed in a __pypackages__ directory.

target is where most build artifacts live but if the SBT "project" has build artifacts too – code that modifies the build environment, generally SBT plugins – then that directory should be cleared as well.

SBT downloads dependencies to a user-level cache that I believe is not appropriate for this tool to evaluate since the cache is shared across all projects the user has interacted with.

When cwd is the root of my home directory (~) and I run kondo or kondo ., it just displays Total bytes deleted: 0.0B and does not even start searching through any directories it looks like.

kondo 0.4.0

edit: same with kondo @ 71d75390f1aa3d5a298e0c086643805cd032c664

For example, the target dir at <rust_project>/examples/<example>/target is ignored, only <rust_project>/target is removed. And if all examples were built for test purposes, the sum of those targets can often exceed the crate's main target

Hi, thanks for this project! It has been really useful for me, by showing me exactly how large those Rust target folders become :)

One nitpick: When I ran kondo on my home directory, it took a very long time. That's ok, you're working on parallelization :+1:. However, I'd have appreciated some kind of output to show me the process hasn't crashed :) Maybe add a --verbose flag and output the name folder that's currently being analyzed?