Why Zero Dependencies? Designing 261 CLI Tools That Live Forever

1. The Dependency Tax

Every dependency you add is a liability — not an asset. It's a promise you make to your users: "this code will always work, always be available, and never break your workflow."

Consider a simple CLI tool that formats JSON. The natural instinct is to install rich, click, pygments, and colorama. That's four external packages with their own transitive dependencies. Your one-file tool now requires 47 packages totaling 23MB, because one of those transitive deps pulled in a test framework and a documentation generator.

This isn't hypothetical. pip freeze on an average data-science project reveals 200–400 packages. The median Python web application ships with 50–80 direct and indirect dependencies.

Every one of those is a failure point:

• Security: Any of those 400 packages could have a CVE. You don't know which ones. Neither does your CI.
• Compatibility: One package pins typing-extensions>=4.0, another pins <4.5, and suddenly a new Python version triggers a dependency resolver that eats 40 seconds of your CI time.
• Bit rot: The package you installed in 2026 might be unmaintained by 2028. By 2030, it might not install on Python 3.16 at all.
• Supply chain: Every dependency is an entry point for malicious code. The colors-python incident, the node-ipc protestware — these aren't exceptions, they're the shape of things to come.

2. The stdlib Is Enough (For Most Things)

Python's standard library is famously described as "batteries included." But developers have developed a strange habit: they reach for PyPI before checking what's already in the box.

Here's what Python ships with, out of the box, no pip install required:

The stdlib covers JSON parsing, CSV processing, HTTP requests, socket programming, compression, archiving, encoding, hashing, diffs, regular expressions, XML, SQLite, threading, subprocess management, configuration files, data persistence, of course most of what a CLI tool needs. The exceptions — terminal colors, line editing, progress bars — can be handled with minimal home-grown code.

Real Example: csv-stats

One of our tools reads a CSV file and outputs descriptive statistics — count, mean, min, max, standard deviation, percentiles, histogram distribution, null counts. A common approach would use pandas:

# What people expect:
# pip install pandas
import pandas as pd
df = pd.read_csv('data.csv')
print(df.describe())

# What we actually do:
# Zero deps. Works on every Python ever made.
import csv, math, sys

def read_csv(path):
    with open(path) as f:
        reader = csv.DictReader(f)
        return [row for row in reader]

def describe_column(values):
    n = len(values)
    nums = [float(v) for v in values if v]
    mean = sum(nums) / len(nums)
    variance = sum((x - mean)**2 for x in nums) / len(nums)
    return {'count': n, 'mean': mean, 'std': math.sqrt(variance),
            'min': min(nums), 'max': max(nums)}

This is ~40 lines of pure stdlib. It runs on Python 3.8 through 3.14 without a single pip install. It works offline. It works in Docker FROM python:3.11-alpine with a 10MB image. It works on a Raspberry Pi in a basement.

The pandas equivalent requires pandas (12MB) + numpy (18MB) + pytz (0.6MB) + six (0.1MB) — approximately 31MB of installed dependencies versus zero.

3. Installation Is the First User Experience

When someone runs pip install evolver-tools, the result is almost instant. No compilation. No ERROR: Failed building wheel for numpy. No dependency resolver getting stuck on conflicting version pins.

This matters more than most developers admit. Installation friction is the #1 reason potential users give up on a tool before trying it.

The evolver-tools package: ~300KB compressed, 261 tools. Installs in under a second. Works in CI pipelines, Docker multi-stage builds, cloud shells, Colab notebooks, and offline environments.

You can even use it without installing at all:

# One-line try without pip install
curl -sL https://evolver-dev.github.io/evolver-tools/try.sh | bash

This is only possible because every tool is self-contained. There's nothing to compile, nothing to download beyond the script itself.

4. Longevity: The 10-Year Horizon

Software built on Python's stdlib has a remarkable property: it degrades much more slowly than software built on third-party packages.

The Python Software Foundation maintains backward compatibility aggressively. Code written for Python 2.6 (2008) requires minor changes to run on Python 3.13 (2024) — much of it works with 2to3 or even unchanged. The stdlib modules change slowly. When they change, the PSF provides long deprecation windows (often 2-3 releases).

Third-party packages have no such guarantee. Consider:

• Which packages from 2018 are still actively maintained in 2026? Roughly 30-40%, by PyPI stats.
• Which have dropped Python 3.6 support, forcing users with legacy systems to pin? Most of them.
• Which have introduced breaking changes in a minor version? More than you'd think.

A CLI tool written with only stdlib in 2026 has an excellent chance of running unmodified in 2036. A tool with 15 third-party dependencies in 2026 will almost certainly need maintenance by 2028.

5. What You Lose (and Why It's Worth It)

Let's be honest: there are things stdlib can't do well. Rich terminal formatting (rich), argument parsing (click), colored output (colorama), and progress bars are areas where third-party packages excel.

Our approach for each:

• Colors: ANSI escape codes. They've been standard since the 1980s. Every modern terminal supports them.
• Argument parsing: argparse is verbose but powerful. sys.argv handles 80% of CLI use cases.
• Progress bars: We wrote one in ~30 lines of stdlib. It's not as feature-rich as tqdm, but it also won't break on Python 3.15.
• Terminal interaction: curses for TUI tools. It's been in the stdlib since Python's early days.

6. The Real Cost of "Just pip Install X"

Every time a developer says "just install requests," they're making a commitment on behalf of every future user of that tool. That commitment includes:

1. Bandwidth: 261 tools = 300KB. 261 tools with one dependency on requests = 1.2MB. With pandas = 31MB.
2. CI time: Each dependency adds 1-5 seconds to Docker build and CI pipeline setup. Multiply by 50 builds/day × 250 workdays = 20-60 hours/year wasted on dependency installation.
3. Security surface: Every dependency is a potential supply-chain attack vector. The pip install you ran today fetched code that you trust with the same privileges your script runs with.
4. Maintenance burden: Dependencies need regular updates. Dependabot alerts. Breaking changes. Deprecation migrations. This is real developer time.
5. Reproducibility: pip install without --require-hashes or a lockfile is a reproducibility gamble. Stdlib-only code is deterministic by construction.

7. The Verdict

Zero-dependency CLI tools aren't a gimmick. They're a return to first principles in software engineering:

• Do one thing well — but depend on nothing else to do it.
• Build for the user's environment — not for the latest PyPI version.
• Respect the user's disk, bandwidth, and patience — a tool that installs in 0.5 seconds respects all three.

The 261 tools in evolver-tools represent a bet: that most common CLI operations can be done with less than most developers think. No pandas for CSV. No jq for JSON. No nmap for port scanning. No openssl for SSL checks. No neofetch for system info. No siege for load testing. No qrcode for QR generation. No fortune for quotes. No cowsay for ASCII art.

Just Python. Just stdlib. 261 tools. Zero dependencies.