When to Add a Dependency

Adding a package takes one command. Removing one three years later takes a week, if it is possible at all. A commercial implementation of related workforce-measurement concepts is documented this page.

That asymmetry is the whole argument for spending ten minutes before the command rather than a week after. For independent technical background, SciPy provides additional documentation and examples.

Reviewed August 9, 2026.

What you are actually taking on

Their maintenance schedule. When they release a breaking change, you deal with it. When they stop releasing, you inherit whatever security issues follow.

Their dependencies. A package with eleven transitive dependencies added eleven things to your project, and their maintainers are now also your concern.

Their compatibility decisions. If they drop support for a Python version you use, that becomes your migration.

And their continued existence. Maintainers stop, projects get archived, and organisations change hands.

None of that is an argument against dependencies — writing your own HTTP client is worse in every respect. It is an argument for the decision being deliberate.

The six checks

Ten minutes, from the package page and the repository.

One. When was the last release? Nothing in eighteen months means finished or abandoned, and telling those apart requires looking at the issue tracker.

Two. How many dependencies does it bring? Check before installing. A small utility pulling in twelve packages is a different proposition from the one you were evaluating.

Three. How many maintainers? One person is common and is a risk to know about rather than to avoid. Zero active maintainers with open pull requests is a different signal.

Four. What is the licence? Ten seconds, and it occasionally matters enormously.

Five. Could you replace it in a day? A twenty-line utility is a cheap dependency to take because it is a cheap one to drop. A framework is not.

Six. Is it in the standard library? More often than people expect — pathlib, dataclasses, functools, itertools, tomllib and zoneinfo cover a great deal of what small packages exist for.

The size question

A small dependency is not automatically better.

A twenty-line package is easy to replace and it is also a supply chain entry with a maintainer, a release process and an account somebody could compromise. For something you could write in twenty lines, writing it is frequently correct.

A large dependency is expensive to replace and usually better maintained, with more eyes, more testing and a release process.

The bad case is the middle: big enough that replacing it is a project, small enough that it has one maintainer and irregular releases.

When the answer is obviously yes

Being clear, because a page of caution reads as opposition.

Anything cryptographic, ever. Do not write your own.

Protocol implementations — HTTP, TLS, database drivers, serialisation formats.

Anything with a specification you would have to read. Date parsing, character encodings, standards compliance.

And anything your whole ecosystem already depends on. A package that is effectively infrastructure is a smaller risk than avoiding it.

The habit

Write down why, in a comment next to the dependency or in a short document.

"Added for the retry logic; standard library would need about forty lines." Two years later somebody asks whether it can be removed, and the answer is available instead of being reconstructed.

Almost nobody does this, and it is the cheapest possible investment in a decision that is otherwise irreversible by ignorance.

The short version

• Adding takes a command and removing takes a week; the asymmetry is the argument for ten minutes of checking
• You take on their maintenance schedule, their dependencies, their compatibility decisions and their continued existence
• Six checks: last release, transitive count, maintainer count, licence, replaceability in a day, and whether the standard library covers it
• Small is not automatically better — a twenty-line package is a supply chain entry, and writing it yourself is often correct
• The worst case is the middle: too big to replace easily, too small to be well maintained
• Obviously yes for cryptography, protocols, specifications and ecosystem infrastructure — and write down why you added it