ick 0.6.0

Applier of fine source code fixes since 2025

Ick

Ick is lightweight polyglot automation for running language-specific tools (including auto-fixes) and letting developers know what they can improve.

Full documentation at https://ick.readthedocs.io.

The problem

Let's say you have a bunch of repos that might need updating.

Not like "format my code" updating, but things that reduce tech debt like moving from pinned urllib3 1.x to urllib3 2.x. That'd be good, right? But maybe not for everyone. And certainly not right now, because you don't want to block pull requests.

The traditional dev loop generally looks like this:

    /----------------\  push  /----------------\
    |  code          |------->|  integrate     |
    |      build     |        |     test       |
    |          test  |        |        deploy  |
    \----------------/        \----------------/

       inner loop                 outer loop

but that discounts the big-picture software maintenance stuff that healthy projects ought to do, and commonly forget (or accomplish with one-off scripts) on a longer term basis. For that we really ought to keep track of things that aren't "right now" and aren't "today" but are "important, yet not urgent".

    /----------------\  push  /----------------\  stable  /==================\
    |  code          |------->|  integrate     |--------->| tech debt week   |
    |      build     |        |     test       |          |  quantified proj |
    |          test  |        |        deploy  |          |   bootcamp tasks |
    \----------------/        \----------------/          |    deprecations  |
                                                          \==================/
       inner loop                 outer loop                 planning cycle

Ick manages and runs rules to help you update repos on your timeline.

Elevator pitch

ick looks at your source code and gives you an evaluation against a set of rules. Those rules might come from a central team at your work, or a trusted friend, or they might be ones you maintain yourself (like my hobbyhorse, "text files must end with a newline").

If you're ever tempted to make a one-off shell script, or create a scripts/release-check.sh that you run once in a while, then ick is the loose automation framework you're looking for. Ick makes that kind of work easier to scale past a couple of repos.

Ick also has the explicit goal of being able to scale from low-risk, easy changes ("text files should end with a newline") to medium changes ("you should drop Python 3.6 support and sync your GitHub actions matrix") to large ones ("here's the beginning of a refactor to enable testcontainers") or even ones that involve external state. The effort to write rules should be roughly proportional to how complex they are -- easy things should be easy (and fast!), but it's OK for hard things to still be hard.

Who is ick for?

• Central teams with opinions. For example, at a company, there might be a language team, a testing team, a load-balancing team, and they all might want to let you know if there are deprecations coming.
• Projects with opinions. Say your ML project has decided to only bless a certain model or license).
• Developers with multiple repositories they want to keep looking similar.
• Developers with hobby horses, who are stricter about things others don't (yet) care about.