The subprocess call

Here's the helper that wraps every git command scaffoldr runs:

def _git(args: list[str], cwd: Path) -> None:
    result = subprocess.run(
        ["git", *args],
        cwd=cwd,
        capture_output=True,
        text=True,
    )
    if result.returncode != 0:
        typer.echo(f"git error: {result.stderr.strip()}", err=True)
        raise typer.Exit(code=1)

subprocess.run executes a command as if you'd typed it in a terminal. The first argument is a list - ["git", *args] - where *args unpacks whatever command-specific arguments get passed in. cwd tells it which directory to run the command in.

Why cwd matters

subprocess.run runs the command starting from Python's own working directory by default - wherever you launched scaffoldr from, not the directory you're turning into a repo. Passing cwd tells it to run the command as if you'd cd'd into that directory first. Without this, git init would initialize a repo in the wrong place.

Capturing output intead of letting it print

capture_output=True redirects the subprocess's stdout and stderr into the result object instead of letting them print directly to the terminal. text=True decodes the output as a string instead of raw bytes, so you can call .strip() directly on result.stderr.

This matters because raw subprocess output would be messy - git's own stdout/stderr mixed in with whatever else scaffoldr is printing at the same time. Capturing it means the error message stays clean and readable: we can print just the relevant part.

Checking for failure

result.returncode is the exit code the git process finished with. 0 means success - this is a convention nearly every command-line program follows, not something specific to git. Any non-zero value means something went wrong.

If returncode != 0, scaffoldr prints the captured stderr and exits with typer.Exit(code=1). This propagates the failure up - if git init fails, scaffold doesn't continue trying to git add and git commit on a repo that was never created.

Running the sequence

Back in scaffold, the actual git setup is three calls:

_git(["init"], cwd=root)
_git(["add", "."], cwd=root)
_git(["commit", "-m", "chore: initial scaffold"], cwd=root)

Initialize the repo, stage every file, commit. Each calls reuses the same _git helper, so error handling for all three is identical - no repeated subprocess.run boilerplate for each command.

What's next

With local scaffolding done - files written, git repo initialized - the next step was making scaffoldr new actually talk to GitHub. That means authenticating, creating a repo through the API, and connecting the local repo to it. That's the next post.

The code is on GitHub

String templates as functions

Each file's content lives in its own function, returning a formatted string. Here's the README:

def readme(project_name: str, author: str) -> str:
    return f"""\
# {project_name}
> Short description of what this project does.
## Installation
```bash
pip install {project_name}
```
## Usage
```bash
{project_name} --help
```
## Development
See [CONTRIBUTING.md](CONTRIBUTING.md) for setup and
contribution guidelines.
## License
{author} - MIT
"""

The \ right after the opening """ strips the leading newline that would otherwise appear before # {project_name}. Without it, the string starts with a blank line.

Every file in the scaffold follows this pattern - a function that takes whatever variables it needs (project_name, author, python_version) and returns the finished file content as a f-string.

Why functions instead of one big template

I could have written this as one function - something that takes every possible variable (project_name, author, python_version, license_) plus a parameter saying which file's content to return - then branching internally to build the right string.

Splitting it into six separate functions instead means each one's signature only lists what it actually uses. gitignore() takes nothing. pyproject() takes project_name, author, license_, python_version. A single dispatcher function would need every one of those parameters available at once, even though most individual files only use a subset.

It also means adding a new content-generating function later doesn't touch the existing ones - no shared dispatcher to extend, no risk of breaking readme() while adding license_file().

Creating the folder structure

The actual scaffolding happens in scaffold:

def scaffold(project_name: str, path: Path) -> None:
    cfg = Config.load()
    root = path / project_name
    if root.exists():
        typer.echo(f"Error: {root} already exists.", err=True)
        raise typer.Exit(code=1)
    typer.echo(f"Creating project at {root} ...")
    (root / project_name).mkdir(parents=True)
    (root / "tests").mkdir()
    (root / "docs" / "adr").mkdir(parents=True)
    (root / ".github" / "workflows").mkdir(parents=True)

Before creating anything, scaffold checks if root already exists and exits with an error if it does. This avoids silently overwriting someone's files.

mkdir(parents=True) creates every missing directory in the path, not just the final one. docs / adr is two levels deep - docs and docs/adr. Without parents=True, you'd need two separate mkdir() calls, one for each level.

Writing the files

Once the directories exist, writing files is straightforward:

(root / "README.md").write_text(readme(project_name, cfg.author))
(root / "CONTRIBUTING.md").write_text(contributing(project_name))
(root / "pyproject.toml").write_text(
    pyproject(
        project_name, cfg.author, cfg.python_version, cfg.license
    )
)

Each file gets written the same way - call the content-generating function, pass the result to Path.write_text().

__init__.py files follow the same pattern, just with empty strings:

(root / "tests" / "__init__.py").write_text("")
(root / project_name / "__init__.py").write_text("")

This makes both the project's own package folder and its test folder proper Python packages.

What's next

At this point, scaffold finishes by initializing git and making the first commit. That's the next post.

The code is on GitHub.

A basic command

Here's the init command as it shipped with v0.1.0:

from pathlib import Path
from typer import Typer
from typer import Argument as typer_argument
from typer import Option as typer_option

app = Typer(help="Scaffold a new project locally")

@app.command("init")
def init(
    project_name: str = typer_argument(
        ..., help="Name of the new project"
    ),
    path: Path = typer_option(
        Path("."), help="Where to create the project"
    ),
) -> None:
    """Scaffold a new project locally."""
    ...

No parser setup. No add_argument calls. The function signature is the whole CLI definition.

Arguments vs options

Typer splits inputs into two kinds: arguments and options.

project_name uses typer_argument. Arguments are positional and required by default. Run scaffoldr init myproject, and myproject fills that slot. The ... as the first value tells Typer that this argument has no default - it must be provided.

path uses typer_option. Options use --flag value syntax, like scaffoldr init myproject --path ~/projects. Options always have a default, set by the first value passed to typer_option. Skip the flag, and it falls back to Path(".").

Type hints drive validation

Look at path: Path. Typer reads that type hint. It converts whatever the user types into a pathlib.Path object. No conversion needed. It arrives as the right type inside the function.

Booleans work the same way. For example:

protect: bool = typer_option(
    True, help="Enable branch protection on main."
)

Typer creates --protect and --no-protect flags automatically. No extra code for that either.

Docstrings become help text

The docstring under the function - """Scaffold a new project locally.""" - isn't just for developers reading the code. Typer shows it when someone runs scaffoldr init --help. The help= argument on typer_argument and typer_option works the same way. It shows per-parameter help text.

The function signature and docstring are the only source of truth for the CLI's documentation.

Registering the entry point

Once the function is decorated with @app.command("init"), it needs to be wired into the installable CLI. In pyproject.toml:

[project.scripts]
scaffoldr = "scaffoldr.main:app"

This tells Python's packaging tools to create a scaffoldr executable. It runs the app object from scaffoldr/main.py. app is the Typer instance every command gets registered to.

What's next

With the CLI shell in place, the next problem was defining what gets created when someone runs scaffoldr init - the folder structure and files that make up a scaffolded project. In v0.1.0, this was hardcoded. That's covered in the next post.

v0.1.0 is shipped. This post is about what I'd change, and what's already queued up for v0.2.0.

The duplicate-run bug

While testing the output formatting, I hit something odd: a single file save sometimes triggered multiple runs of the configured command. I don't have the root cause yet, but I have suspects.

Most likely

• notify-debouncer-full itself might be batching events in a way that lets duplicates slip through before my filtering logic catches them

• If the channel sender gets cloned more than once for the same entry, that could cause a duplicate send

Less likely

• The debounce window may not be catching both events if they land far enough apart

• Multiple debouncers could be watching overlapping directories and each reporting the same change

The first two feel more likely given how I hit this: a single entry in Neovim, whose write pattern should fit comfortably inside the default 500ms window. That points more toward the debouncer's internal batching or a channel-cloning issue.

This is a real bug, not a nice-to-have. It goes against the exact thing debouncing is supposed to guarantee: one save, one configured command run.

Better logging

Better logging gives visibility into what watchr is doing internally - which events fired, how debouncing grouped them, what decisions got made along the way. This matters for diagnosing bugs like the one above, where the actual cause is still unclear without seeing what happened internally at the moment it occurred.

The plan: add tracing, a structured logging crate for Rust. watchr can then report what it's doing internally at different verbosity levels.

This is separate from command output (that's the result of your command). Tracing logs are about what watchr itself is doing, and only show up if you ask for them.

Knowing which watcher fired

If you configure more than one [[watcher]] entry, watchr can't tell you which one triggered a given command.

The event only holds the command string, not the entry name:

pub enum WatchEvent {
    Command(String),
    Shutdown,
}

Fixing this means adding the entry name to Command, so output can say which watcher ran, not just what it ran. Small change, but it matters once you have more than one entry watching different things.

Naming cleanup

Some types are named Watcher-something (WatcherError), others are named Watchr-something (WatchrConfig). There's no rule - it just happened inconsistently.

That's not a bug, but it's friction. Every time I add a new type, or use an existing type, I have to stop and think about which spelling to use.

v0.2.0 standardizes on Watcher everywhere internally, keeping watchr only as the name of the CLI tool.

What I'd tell myself starting over

Decide naming conventions before writing the first struct. Fixing inconsistent names later means touching files that already work - tedious, and slows down your flow.

Test the actual user-facing output earlier. The raw debug output from weeks ago looked bad, but I didn't notice until I actually used it. I was testing that the logic worked, not that the output was usable. Those are different things.

Where this leaves things

v0.1.0 works. The remaining gaps are known, filed, and scoped - which is where I want to be before v0.2.0. If you want to follow the actual work, the issues are public on the watchr repo.

What it looked like

Initially, watchr ran your command and printed whatever it got back - straight from Rust's debug formatting:

match output {
    Ok(out) => println!("{:?}", out),
    Err(e) => println!("{:?}", e),
}

Here's the output looked like after running a test suite:

Output { status: ExitStatus(unix_wait_status(0)), stdout: "test\n", stderr: "" }

Technically correct. Yet, completely unreadable. You're staring at Rust's internal struct representation instead of your test results.

Why this mattered

watchr's whole job is running your command and showing you what happened. If the output is unreadable, the tool fails its purpose.

This wasn't a "nice to have" fix. It was a release blocker. Shipping v0.1.0 with debug structs as the primary output would've made the tool unusable.

Designing the fix

Before writing the code, I finalized what the user actually needs to see:

• The command that was run.

• Did the command succeed or fail?

• If it failed, why - an exit code, or did it not even run?

• What did the command actually print?

That's it. No Rust internals, no exposed structs.

The fix

fn print_output(
    cmd: &str,
    output: Result<process::Output, std::io::Error>,
) {
    println!("$ {}", cmd);

    match output {
        Ok(out) if out.status.success() => {
            println!("✓ success");
            match String::from_utf8_lossy(&out.stdout).trim() {
                "" => println!("(no output)"),
                out => println!("{}", out),
            }
        }
        Ok(out) => {
            match out.status.code() {
                Some(code) => {
                    println!("✗ failed (exit code {})", code)
                }
                None => println!("✗ failed (terminated)"),
            }

            match String::from_utf8_lossy(&out.stderr).trim() {
                "" => eprintln!("(no output)"),
                err => eprintln!("{}", err),
            }
        }
        Err(e) => {
            println!("✗ failed to spawn: {}", e);
        }
    }
}

Walking through the three cases:

• Ok(out) if out.status.success() - the command ran and succeeded. Print a checkmark, then the command's actual output.

• Ok(out) (the fallthrough) - the command ran but failed. Show the exit code if there is one, or "terminated" if the process was killed by a signal instead of exiting normally. Then print stderr.

• Err(e) - the command never ran at all. This happens if, say, the shell itself couldn't be found.

It is worth noting that Command::output() returns a Result<Output, io::Error>, not just Output. Okmeans the process spawned successfully (whether it succeeded or failed is a separate question, answered by status).Err means it couldn't even start.

String::from_utf8_lossy turns the raw bytes from stdout and stderr into a displayable string. .trim() matters because command output often ends in a trailing newline, or is nothing but whitespace. Without trimming, that would fail to match the "" case and print a blank line instead of "(no output)". A blank line looks like the tool might be stuck. A clear label prevents this confusion.

What you get now

$ cargo test
✓ success
running 20 tests
test cli::tests::test_is_init_true ... ok
...
test result: ok. 20 passed; 0 failed

No debug structs. Success or failure is the first thing you see, not something you have to dig for.

Next

A retrospective on what's changing in v0.2.0

The problem

watchr runs in a loop, watching files and running commands forever, until you stop it. The obvious way is to hit Ctrl+C.

But Ctrl+C sends a signal that kills your process immediately. No cleanup, no "wrapping up now" message. If watchr were mid-command when you hit Ctrl+C, the process would just stop - no final message, no confirmation it actually shut down cleanly.

This is bad for UX. I wanted watchr to catch Ctrl+C, print something reassuring, and exit cleanly.

The approach: a channel and an extra event

watchr already uses a channel to pass events from its file watchers to the main loop. Channels in Rust are a way for one part of your code to send messages to another, even across threads. One side holds a Sender, the other holds a Receiver.

Here's the event type:

#[derive(Debug)]
pub enum WatchEvent {
    Command(String),
    Shutdown,
}

The #[derive(Debug)] attribute is a Rust feature that automatically generates code to print these values for debugging. The enum itself defines two possible types of events the system can handle: Command (when a file changes) and Shutdown (when the user exits).

The Shutdown variant was added to support graceful shutdown. The channel still carries the same WatchEvent type - it just now has two cases.

Why not just use a bool flag?

You might wonder: why not just use a shared AtomicBool flag that the Ctrl+C handler sets to true? That works too, but it means adding a check on every loop iteration, and reasoning about when exactly that flag gets read.

Routing shutdown through the existing channel is cleaner: the event loop already blocks on rx.recv() waiting for the next thing to do. Shutdown is just another message that the loop has to handle. No new synchronization mechanism to reason about.

Installing the Ctrl+C handler

fn create_shutdown_handler(
    tx: Sender<WatchEvent>,
) -> Result<(), WatcherError> {
    ctrlc::try_set_handler(move || {
        let _ = tx.send(WatchEvent::Shutdown);
    })?;
    Ok(())
}

ctrlc::try_set_handler takes a closure and runs it when Ctrl+C is pressed. The closure here does one thing: send WatchEvent::Shutdown down the channel.

That's the whole trick. Ctrl+C doesn't kill anything directly. It just drops a message in the same queue the file watchers already use.

Handling it in the event loop

fn run_event_loop(rx: Receiver<WatchEvent>) {
    loop {
        match rx.recv() {
            Ok(WatchEvent::Command(cmd)) => {
                let output = process::Command::new("sh")
                    .arg("-c")
                    .arg(&cmd)
                    .output();

                print_output(&cmd, output)
            }
            Ok(WatchEvent::Shutdown) => {
                println!("Shutting down gracefully...");
                break;
            }
            Err(_) => break,
        }
    }
}

This loop calls rx.recv() and blocks until a message shows up. The match statement checks what type of event we received.

If it's a Command, run it. If it's Shutdown, print a message and break out of the loop - which ends the function and terminates the program.

No special-casing, no separate shutdown path. Shutdown is just another message the loop has to handle.

What you get

Hit Ctrl+C, and watchr prints "Shutting down gracefully..." and exits. No abrupt kills, no wondering if all command runs were actually terminated.

Next

The story behind issue #23 - how watchr's command output went from unreadable debug structs to something that is actually useful.

The problem

You hit save in your editor. Feels like one event, right? It often isn't. A single save can fire off several filesystem events within milliseconds — a write, a metadata update, sometimes a temp-file-then-rename depending on your editor.

If watchr reacted to every event, one save would trigger cargo test two or three times in a row. That's wasteful, and confusing if you don't know what is happening.

Debouncing fixes this. Instead of reacting to every event immediately, you wait a short window to see if more events are coming. If several arrive close together, you treat them as one and react just once.

Why not raw notify?

notify is Rust's standard crate for watching files. It's solid but low-level - it hands you raw events as they happen, with no grouping or debouncing built in.

Using it directly would mean building my own debounce logic: a timer, a buffer for pending events, and logic to determine if the debounce window has closed. Doable, but not the problem I set out to solve.

So I used notify-debouncer-full instead. It wraps notify and handles debouncing for you. The tradeoff is less low-level control and one more dependency - a fair trade for not increasing the likelihood of introducing bugs.

The code

Here's the function that sets up a watcher for each entry in your config:

fn create_debouncers(
    debounce_ms: u64,
    entries: Vec<WatchrEntry>,
    tx: Sender<WatchEvent>,
) -> Result<
    Vec<Debouncer<RecommendedWatcher, NoCache>>,
    WatcherError,
> {
    let mut debouncers = Vec::new();
    for entry in entries {
        let tx = tx.clone();

        let mut debouncer = new_debouncer(
            Duration::from_millis(debounce_ms),
            None,
            move |result: DebounceEventResult| {
                handle_events(
                    result,
                    entry.ext.clone(),
                    entry.command.clone(),
                    tx.clone(),
                );
            },
        )?;

        for dir in &entry.dirs {
            debouncer.watch(dir, RecursiveMode::Recursive)?;
        }
        debouncers.push(debouncer);
    }
    Ok(debouncers)
}

Each [[watcher]] entry in your .watchr.toml gets its own debouncer, watching its own directories with its own command.

Duration::from_millis(debounce_ms) sets the wait window - your debounce_ms value from the config. This is how long watchr waits for things to go quiet before treating a burst of events as one.

The closure passed into new_debouncer is the callback that runs once the window closes. It receives a batch of grouped events and hands them off to handle_events, which checks if they match your configured file extensions before running anything.

debouncer.watch(dir, RecursiveMode::Recursive) registers each directory to be watched, including subdirectories.

What this buys you

Your editor fires three events for one save. watchr waits, groups them, and treats them as one change. You get exactly what you expect: one save, one command run.

One known gap: certain saves still trigger a command multiple times. This is a real bug, and I'll cover the fix in a later post on v0.2.0 changes.

Next

How watchr shuts down cleanly when you hit Ctrl+C, instead of getting killed mid command.

watchr needs to know which directories to watch, which file extensions matter, and what command to run when something changes. That means a config file, and a config file means picking a format. Here's why I ended up picking TOML over YAML, even though it's the more familiar choice for a lot of people.

What I actually needed

Before picking a format, I wrote down what mattered:

• Human readable: someone should be able to open the file and understand it without a manual

• Human editable: no weird escaping rules that make you afraid to touch it

• Good tooling support: I didn't want to hand-roll a parser

Just "a normal person should be able to write this by hand."

Why not YAML

YAML is the obvious first candidate. It's used in Docker Compose, GitHub Actions, Kubernetes. If you've written a config file in the last few years, odds are it was YAML.

But YAML has some well-known pitfalls. One is implicit typing. YAML tries to guess what type a value is. Type yes and YAML might quietly turn it into the boolean true instead of the string "yes". If you're not expecting that, it's a confusing bug to track down.

The Norway Problem is a famous example of this. Write the country code NO without quotes, and YAML parses it as false. Your country code silently becomes a boolean. That's the kind of surprise I didn't want baked into a file that users are hand-editing.

Another notable pitfall is the strict indentation rules that can lead to unexpected errors.

None of this makes YAML bad - it's used everywhere for good reasons. But for a small CLI tool's config file, I wanted fewer sharp edges.

Why TOML

TOML (Tom's Obvious, Minimal Language) is built to avoid this kind of ambiguity. Strings need quotes. Types are explicit. You always know exactly what you're getting.

Here's a real watchr.toml file:

debounce_ms = 500

[[watcher]]
name = "tests"
dirs = ["src/"]
ext = ["rs", "toml"]
command = "cargo test"

[[watcher]]
name = "lint"
dirs = ["src/"]
command = "cargo clippy"

Walking through this:

• debounce_ms=500 is a plain integer.

• [[watcher]] defines an array of tables - TOML's way of saying "here's a list of entries, and each one has its own section below it." Every [[watcher]] starts a new entry.

• dirs = ["src/"] and ext = ["rs", "toml"] are arrays of strings. Explicit, quoted, no surprises.

• command = "cargo test" is just a string. What you type is what you get.

YAML can express all this too. The risk isn't that it can't - it's that small mistakes like a missing quote are easy to make and hard to spot.

TOML also has strong tooling support across languages, including Rust, where the toml crate makes parsing this into a config struct straightforward.

The tradeoff

If you're coming from a JavaScript or Python background, you're probably more used to JSON or YAML, so TOML might feel like one more syntax to learn.

But for a file that users hand-edit, hand-write, and copy-paste between projects, trading unfamiliarity for a format that doesn't quietly turn NO into false felt justified.

What's next

Next up: how watchr actually watches files and handles debouncing - the part where rapid file saves don't trigger a dozen redundant command runs.

What I built

scaffoldr is a Python tool that handles all this in one command. Run scaffoldr new myproject and you get a local project with an opinionated directory structure, a GitHub repo created via the API, an initial commit pushed, default issues opened, and branch protection configured on main. What used to take 20-30 minutes and a checklist now takes seconds.

Getting started

Clone the repo and install locally:

git clone https://github.com/mg4603/scaffoldr.git
cd scaffoldr
pipx install .

Set up your config once:

scaffoldr config init

This creates ~/.config/scaffoldr/config.toml with your GitHub username, token and preferences. Then scaffold a new project:

scaffoldr new myproject --description "What it does"

If you just want the local repo without the GitHub setup:

scaffoldr init myproject

Not sure what you'll get? Run with --dry-run first:

scaffoldr new myproject --dry-run

Templates

By default scaffoldr uses a built-in Python project template. You can define your own in ~/.config/scaffoldr/templates/ and pass it with --template:

scaffoldr new myproject --template mytemplate

Validate a template before using it:

scaffoldr template validate ~/.config/scaffoldr/templates/mytemplate.toml

How it works

scaffoldr talks to the GitHub API via httpx. Local scaffolding renders a TOML template using Python's str.format_map, writes the files, then runs git init, git add ., and an initial commit via a subprocess. scaffoldr then calls the GitHub API to create the repo, push the initial commit via the configured remote (SSH or HTTPS with token embedding), open the default issues, and set branch protection on main.

What's next

The code is on GitHub. v0.2.0 just shipped with user defined templates, a --dry-run flag, and a template validate command. Feel free to open an issue if you have ideas or run into bugs.

Every dev has been there - you save a file, switch to the terminal, run the tests, switch back. Save, switch, run, switch back. It's just constant friction that breaks your flow. watchr eliminates that loop entirely by watching your directories and running commands automatically the monent something changes.

What watchr Does

watchr is a Rust CLI tool that watches one or more directories for file changes and runs a command in response. You configure it once, either via a .watchr.toml or directly on the CLI, and it handles the rest. Save a file, whatever you've configured for that directory runs automatically. No switching, no manual re-runs.

How It Works Under the Hood

watchr uses notify-deboucer-full for efficient filesystem monitoring. The debouce window prevents multiple runs from triggersing when you save repeatedly in a short period. Commands are executed via sh -c so you can chain them with &&, use pipes, or run anything you'd normally type in a shell.

Installation

git clone https://github.com/mg4603/watchr.git
cd watchr
cargo build --release
# Binary will be at target/release/watchr

cargo install --path . 
# To install to local Cargo bin dir

Quick Start

watchr watch src/ --cmd "cargo test"

Filter by extension:

watchr watch src/ --ext rs,toml --cmd "cargo test"

Using a Config File

For anything beyond a single watchr, a .watchr.toml is the right move. Generate a template:

watchr init

Then edit it:

debounce_ms = 500

[[watcher]]
name = "tests"
dirs = ["src/", "tests/"]
ext = ["rs"]
command = "cargo test"

[[watcher]]
name = "lint"
dirs = ["src/"]
command = "cargo clippy"

Start watching:

watchr watch

watchr walks up the directory tree to find .watchr.toml automatically. You can also point it at an explicit path:

watchr watch --config ~/my-project/.watchr.toml

Get the Code

Full source at GitHub. If it save you a few hundred manual test runs, give it a star.

If you've ever recorded a screencast or a demo video, you've probably experienced this: you play it back and all you can hear is the hum of your pc, the fan in the background, or streetnoise bleeding through your window. Fixing it means either buying expensive equipment, building a makeshift soundproof setup, or just putting out bad audio and hoping nobody notices. None of these are good options. denoiser is a simple CLI tool that cleans your audio in one command.

What denoiser Does

denoiser takes your video file, builds a noise profile from a short sample of background noise at the beginning, and uses that profile to strip the noise from the entire recording. The result is cleaner audio without touching your recording setup.

How It Works Under the Hood

Under the hood, denoiser uses the noisereduce library to do the heavy lifting. It samples a configuration duration of audio from the start of your file, defaulting to the first 2 seconds, treats that as the noise floor, and applies spectral gating across the full track to suppress it. The --prop-decrease flag controls how aggressively the noise is reduced.

Installation

git clone https://github.com/mg4603/denoiser.git
cd denoiser
pipx install .

Basic Usage

denoiser denoiser input.mp4 output.mp4

That's it. Default work well for most recordings.

The Flags Explained

• --noise-reduce (default: 2.0): how many seconds from the start of the file are used to build the noise profile.
• --prop-decrease (default: 1.0): how aggressively noise is reduced. 1.0 is full suppression. If output sounds hollow or over-processed, try 0.7 or 0.8.

denoiser denoise --noise-duration 1.5 --prop-decrease input.mp4 output.mp4

Get the Code

The full source is on GitHub. If this saves you a reshoot, git it a star.

What I built

logsnap is a Python CLI tools that lets you tail mutliple log files in one place, filter output by keyword, and snapshot the results for later analysis. Instead of juggling three terminals, you run one command and see everything in one unified view.

Getting started

Clone the repo and install locally:

git clone https://github.com/mg4603/logsnap.git
cd logsnap
pipx install .

Initialize your config:

logsnap config init

This creates a config file at ~/.config/logsnap/config.toml. Edit it to point at your log files:

[sources]
files = [
    "/var/log/syslog",
    "/var/log/app.log"
]

Then run:

logsnap watch

Every line is timestamped and prefixed with its source file so you always know where output is coming from. When you see somthing worth saving:

logsnap snap

Snapshots export in either plain text or JSONL format - useful if you want to query them later.

How it works

No external file-watching library. logsnap opens each log file, seeks to the end, then polls for new lines every 100ms. New lines get timestamped, tagged with their source path, written to your terminal and buffered to a session file simultaneously. Simple, dependency-light, and easy to extend.

What's next

The code is on GitHub. Feel free to open an issue or submit a PR if you have ideas or run into bugs.