DEV Community: repowise

Bus factor 1 is the default: per-language ownership in 195 popular repos

Raghav Chamadiya — Sat, 14 Nov 2026 13:00:00 +0000

TL;DR

Bus factor is the fewest people who together made 80% of a file's commits; a bus factor of 1 means one person made 80% or more of them.
In the median of 195 popular open-source repos (1,000+ GitHub stars), 60% of production files have a bus factor of 1, and in 124 of the 195 those files are the majority.
Busy files are more shared: in the median repo, 25% of hotspot files have a bus factor of 1.
Numbers come from repowise's index of those 195 repos (November 2026), plus a git shortlog script run on a full clone of Django.

Bus factor (also called truck factor) is the number of people who would have to disappear before nobody left understands a piece of code. A bus factor of 1 means one person holds it.

It sounds like a warning sign. Across 195 popular open-source repositories, it is the normal state of most files.

How do you calculate bus factor?

For a single file: the fewest authors who together made 80% of its commits. If one person made 80% or more of the commits, the file has a bus factor of 1. If it takes two people to reach 80%, it is 2, and so on.

Commits are a rough proxy for knowledge, but every repo already has them. git blame is worse for this, because a formatter run or a big rename hands whole files to whoever pressed the button.

Compute it for one file

git shortlog -sn counts commits per author and sorts them, highest first. Walk down that list until you pass 80%:

#!/usr/bin/env bash
# busfactor.sh <file> [git log options]
f="$1"; shift
git shortlog -sn --no-merges "$@" HEAD -- "$f" |
  awk '{c[NR] = $1; t += $1}
       END {for (i = 1; i <= NR; i++) {s += c[i]; if (s >= 0.8 * t) {print i; exit}}}'

On a full clone of Django (HEAD 6a8248f, 10 November 2026), for the QuerySet module:

$ ./busfactor.sh django/db/models/query.py
54
$ ./busfactor.sh django/db/models/query.py --since="2 years ago"
20

Fifty-four people made 80% of the commits to query.py over 21 years, and 20 people over the last two. That is about as far from 1 as a file gets.

Two details matter in that script. HEAD is explicit because git shortlog with no revision reads standard input when it is not attached to a terminal, which inside a script means it prints nothing. And the --since option is not decoration. The people who wrote a file in 2012 are not necessarily the people who could fix it today, so the window you pick changes the answer.

Run it over every .py file under django/:

git ls-files 'django/*.py' | while read -r f; do
  echo "$(./busfactor.sh "$f") $f"
done | awk '$1 == 1 {b++} END {print b " of " NR " files have bus factor 1"}'

151 of 909 files have bus factor 1

Now the same loop with --since="2 years ago" passed through, counting only the files that had commits in that window:

git ls-files 'django/*.py' | while read -r f; do
  echo "$(./busfactor.sh "$f" --since="2 years ago") $f"
done | awk 'NF == 2 {n++; if ($1 == 1) b++} END {print b " of " n " files with commits have bus factor 1"}'

136 of 460 files with commits have bus factor 1

17% over Django's whole history, 30% over the last two years. Same code, same rule, a different window. Django is also one of the most widely shared codebases in open source. Most projects look different.

How common is a bus factor of 1 in open source?

I looked at production source files (tests, generated and vendored code excluded) in 195 public repositories with 1,000+ GitHub stars each, using the same 80% rule on each repo's indexed git history.

In the median repo, 60% of production files have a bus factor of 1.
In 124 of the 195 repos (64%), files with a bus factor of 1 are the majority.

By primary language (GitHub's label for the repo), median share of production files with a bus factor of 1:

Language	Repos	Files with bus factor 1
Rust	15	79%
TypeScript	52	70%
C#	10	66% (small group, indicative)
Python	51	57%
Go	22	49%
JavaScript	13	45% (small group, indicative)
C++	8	44% (small group, indicative)
All 195	195	60%

I would not read too much into the language order. Bus factor depends heavily on how long a project has existed and how many regular contributors it has, and those vary more between repos than between languages. A three-year-old project has had far less time to spread knowledge around than Django has in 21.

Are the most-changed files single-owner?

The more useful number is about hotspots, the files that change most often. If the busiest files were also single-owner, that would be a real risk: lots of change going through one person's head.

The data says the opposite. In the median repo, 25% of hotspot files have a bus factor of 1, against 60% of all production files. Pooled across the 195 repos, 34% of 20,941 hotspot files are single-owner. Code that changes a lot tends to get touched by more people, which is what you would hope.

So a bus factor of 1 on a file nobody edits is mostly fine. The case worth acting on is a file that is still changing often while its main author has gone quiet.

What should you do about a bus factor of 1?

Find the overlap first: files with a bus factor of 1 that are also in the top 10% by recent churn (lines added plus deleted in the last 90 days, which git log --numstat gives you). Start with that list.
Route reviews on those files to a second person on purpose, even when the owner could review alone.
Ask the owner for a short note on intent: why it is shaped like this, what not to change. Ten lines in a docstring or an ADR outlast a handover meeting.
Do not chase a number. A bus factor of 2 on a stable utility file is not worth a reorg.

The full method, including .mailmap for people with several email addresses and how to run this across a whole repo, is in this guide on measuring bus factor from git. For a large repo you can browse, Grafana's owners page shows bus factor per file across its 10,000+ production files. At its last index, 24% of them had a bus factor of 1, well under the median.

How does your team handle single-owner files that still change every week?

How I got these numbers

The cohort is 195 of the most-starred public repositories indexed on repowise (1,000+ GitHub stars each, 253,688 production source files, November 2026), each measured at its own latest index between May and November 2026. The cohort-wide ownership numbers are finding 8 of the code health 2026 report. Bus factor is computed per production file from each repo's indexed git history with the 80% rule above. No author names were collected or used. The Django runs are the script above on a full clone at 6a8248f.

FAQ

What does the term bus factor mean?
Bus factor, also called truck factor, is the number of people who would have to leave a project before nobody left understands a piece of code. Here it is measured per file as the fewest authors who together made 80% of its commits.

How do you calculate bus factor from git?
Run git shortlog -sn --no-merges HEAD -- <file> to count commits per author, highest first, then add authors down the list until you pass 80% of the commits. The number of authors you needed is the bus factor. Add --since to measure only recent history.

Is a bus factor of 1 bad?
Not on its own. It is the normal state of 60% of production files in the median popular repo, and a single-owner file nobody edits is mostly fine. The case to act on is a file that still changes often while its main author has gone quiet.

TypeScript unused exports: what 52 popular TS repos carry, and how to clean yours with Knip

Raghav Chamadiya — Fri, 13 Nov 2026 13:00:00 +0000

TL;DR

Knip finds unused files, unused exports and unused dependencies in JavaScript and TypeScript projects by following imports from your entry points, and npx knip runs it with no config.
In repowise's index of 48 popular TypeScript repos (1,000+ GitHub stars), unused exports (5,759) outnumber files flagged as unreachable (2,189) more than 2 to 1.
tsc's noUnusedLocals does not catch unused exports, because it checks one file at a time.
Clean up in this order: delete unused files, remove unused dependencies, run knip --fix --fix-type exports, then delete what tsc now reports as unused.

Knip finds unused files, exports and dependencies in JavaScript and TypeScript projects. Two parts follow: what the dead code in 52 popular TypeScript repositories actually looks like, and a walk through Knip's output on one of them, repomix, including the cleanup order that does not break your build.

How many unused exports do popular TypeScript repos have?

Using repowise's index of 195 public repositories with 1,000+ GitHub stars each (November 2026), I looked at production source files (tests, generated and vendored code excluded) in its 52 TypeScript repos. Dead-code findings were available for 48 of the 52.

46 of 48 have at least one dead-code finding in production code.
42 of 48 have at least one unused export: an exported symbol that nothing in the repo imports.
The median repo has 10.1 findings per 100 production files, and 1.7% of its production files are flagged as unreachable (nothing imports them and they are not an entry point).

Pooled across the 48 repos: 5,759 unused exports and 2,189 unreachable files, in 66,599 production files (the dead code section of the code health 2026 report has the numbers for all 195 repos). In TypeScript, the unused export is the common case. Whole forgotten files are the rarer one.

A few recognisable repos, each measured at its own latest index:

Repo	Production files	Unused exports	Files flagged unreachable	Indexed
grafana/grafana	10,090	1,050	171	2026-10-28
shadcn-ui/ui	3,853	253	69	2026-11-04
renovatebot/renovate	1,471	75	3	2026-08-02
anthropics/claude-code	899	1	6	2026-09-27
GrapesJS/grapesjs	364	0	0	2026-10-19
effector/effector	242	30	22	2026-10-08
yamadashy/repomix	209	0	0	2026-06-16

Context decides what each finding means. I re-ran shadcn-ui/ui on a fresh clone (commit 8ab2771) and got 327 candidates. 251 of them sit in apps/v4/registry/, the component registry. Nothing in the repo imports those components because they are not meant to be imported there: apps/v4/registry.json lists each file by path ("path": "registry/new-york-v4/ui/accordion.tsx"), and the shadcn CLI copies them into your project. The tool marked none of the 327 as ready to delete. A code health page like shadcn's is a good way to read such a list in context, and the same rule holds with any tool: a file loaded by path from a manifest is used, even with zero importers.

How do you use Knip?

I ran Knip on repomix, the last row of the table, at commit 758c3d7 (November 8, 2026). Its dependencies were installed and there was no Knip config. It took 19 seconds:

$ npx knip
Unused files (113)
browser/entrypoints/background.ts
browser/entrypoints/content.ts
...
tests/fixtures/config-ts/repomix.config.ts
...
website/server/src/index.ts
website/server/warmup.mjs
Unused dependencies (1)
@repomix/tree-sitter-wasms  package.json:84:6
Unused devDependencies (1)
@types/strip-comments  package.json:114:6
Unlisted binaries (2)
hyperfine  package.json
pinact     package.json
Unused exports (16)
outputPatternSchema                          src/config/configSchema.ts:27:14
...
validateGitRef                               src/core/git/gitCommand.ts:306:14
TOKEN_ENCODINGS                              src/core/metrics/TokenCounter.ts:8:10
getSupportedLanguages              function  src/core/treeSitter/languageConfig.ts:239:17
...
isMac                                        tests/testing/testUtils.ts:53:14
isLinux                                      tests/testing/testUtils.ts:54:14
Unused exported types (8)
...
Duplicate exports (1)
repomixConfigBaseSchema|repomixConfigFileSchema  src/config/configSchema.ts
Configuration hints (1)
. (root)    .  Create knip.json configuration file, and add entry and/or refine project files (113 unused files)

That is 142 findings. Here is what they turned out to be.

Unused files: 113, and none of them is dead. 83 are in website/ (the repomix.com client and server), 7 in browser/ (the browser extension) and 2 in scripts/memory/. Each of those folders is its own npm project with its own package.json, and the root package.json declares no workspaces, so to Knip they are files that nothing imports. The other 21 are test fixtures that the tests read from disk by path, for example path.join(process.cwd(), 'tests/fixtures/config-ts'). Knip's last line points the same way: add a config.

Unused dependencies: one false, one true. @repomix/tree-sitter-wasms is used. loadLanguage.ts resolves the grammar files by path, `@repomix/tree-sitter-wasms/out/tree-sitter-${langName}.wasm`, so there is no import for Knip to follow. Same lesson as the shadcn registry. @types/strip-comments really is unused: the code imports @repomix/strip-comments, a fork that ships its own index.d.ts, so the old types package types nothing. The two unlisted binaries, hyperfine and pinact, are system tools called from npm scripts.

Unused exports: 16, and 12 of them are used. validateGitRef is exported from gitCommand.ts and called on line 192 of the same file. Knip asks whether another file imports an export, and for 12 of the 16 the answer is no, but the file itself uses them. Only the export keyword is unused. With "ignoreExportsUsedInFile": true in the config, the list drops to 4:

getSupportedLanguages in languageConfig.ts has no caller anywhere in the repo.
TOKEN_ENCODINGS in TokenCounter.ts is a re-export kept "for backward compatibility" when the constant moved to tokenEncodings.ts to speed up startup. Every caller now imports it from the new file, so the compatibility line has outlived its callers.
isMac and isLinux are test helpers in tests/testing/testUtils.ts that no test uses.

The table's 0 for repomix is repowise's June index. This is Knip on a November commit, and Knip counts an export used only inside its own file as unused, which is 12 of these 16.

Knip exits with code 1 when it finds something, so npx knip works as a CI check as-is.

Why doesn't tsc catch unused exports?

repomix with noUnusedLocals turned on, before any cleanup:

$ npx tsc --noEmit --noUnusedLocals
tests/core/output/diffsInOutput.test.ts(109,11): error TS6133: '_output' is declared but its value is never read.
tests/core/output/diffsInOutput.test.ts(183,11): error TS6133: '_output' is declared but its value is never read.

Two unused variables in a test, and none of the 24 exports and types Knip listed. noUnusedLocals and @typescript-eslint/no-unused-vars look inside one file at a time. An exported symbol is part of the file's interface, so from the file's point of view it is always used. Finding exports that nobody imports needs a tool that reads the whole project's import graph, which is what Knip does.

Clean up in the right order

Knip can fix exports for you. It removes the export keyword. On repomix, with the config from the next section so it leaves website/ alone:

$ npx knip --fix --fix-type exports,types
...
Unused exports (16)
validateGitRef                               src/core/git/gitCommand.ts:306:14              (removed)
TOKEN_ENCODINGS                              src/core/metrics/TokenCounter.ts:8:10          (removed)
LANGUAGE_CONFIGS                             src/core/treeSitter/languageConfig.ts:64:14    (removed)
getSupportedLanguages              function  src/core/treeSitter/languageConfig.ts:239:17   (removed)
...

24 lines changed in 17 files. Two of them:

-export { TOKEN_ENCODINGS, type TokenEncoding };
+export {  type TokenEncoding };
-export const LANGUAGE_CONFIGS: readonly LanguageConfig[] = [
+const LANGUAGE_CONFIGS: readonly LanguageConfig[] = [

The build still passes. Now run the compiler with noUnusedLocals:

$ npx tsc --noEmit
$ npx tsc --noEmit --noUnusedLocals
src/config/configSchema.ts(38,6): error TS6196: 'FileProcessorOnError' is declared but never used.
src/config/configSchema.ts(208,6): error TS6196: 'RepomixConfigDefault' is declared but never used.
src/core/metrics/TokenCounter.ts(4,10): error TS6133: 'TOKEN_ENCODINGS' is declared but its value is never read.
src/core/treeSitter/languageConfig.ts(239,10): error TS6133: 'getSupportedLanguages' is declared but its value is never read.
tests/core/output/diffsInOutput.test.ts(109,11): error TS6133: '_output' is declared but its value is never read.
tests/core/output/diffsInOutput.test.ts(183,11): error TS6133: '_output' is declared but its value is never read.
tests/testing/testUtils.ts(53,7): error TS6133: 'isMac' is declared but its value is never read.
tests/testing/testUtils.ts(54,7): error TS6133: 'isLinux' is declared but its value is never read.

Six new lines: the four exports and two of the three types that nothing uses at all. The third type, SecurityCheckType, was a pass-through re-export, so removing it left nothing behind to flag. The compiler stays quiet about the other 17, because their own files use them. Knip and the compiler work as a pair: Knip finds what is unused across files, and the compiler finds what is unused inside one.

repomix has no dead files, so this run cannot show the other trap. Knip does not count imports that come from unused files. If a dead file is the only importer of a helper, Knip reports the helper's export as unused, --fix removes the export, and the dead file stops compiling. Delete unused files first.

So the order I use:

Delete unused files (--allow-remove-files lets --fix do it, but I prefer to read each one first).
Remove unused dependencies.
Run knip --fix --fix-type exports.
Run tsc and delete whatever it now reports as unused.
One pull request per step, so each review is boring.

How do you configure Knip for a real project?

On an application, Knip's plugins detect most frameworks and add their entry points for you (Next.js pages and routes, Vite, Vitest, Storybook and many more). What is left is usually scripts, fixtures, generated code and folders that are their own project. The config I used on repomix:

{
  "ignore": ["website/**", "browser/**", "scripts/memory/**", "tests/**/fixtures/**"],
  "ignoreBinaries": ["hyperfine", "pinact"]
}

Two lines take the run from 142 findings to 27. Ignoring website/ and browser/ is the quick version. The thorough one is to run Knip inside each of those projects too, since each has its own entry points. "ignoreDependencies": ["@repomix/tree-sitter-wasms"] would clear the last false positive.

Start with no config, read the report, and add one line per false positive. If a whole category is wrong, it is almost always a missing entry point or a folder that is really a separate project.

On a library, the public API is whatever package.json exposes through main, exports or bin. By default Knip does not report unused exports from those entry files, because your users import them. --include-entry-exports turns that on when you want to audit the public surface itself. That one default is the biggest reason different unused-export tools disagree on the same repo, which this comparison of Knip, ts-prune and unimported measured on one real monorepo.

Barrel files

Knip follows export * through barrel files, so a barrel does not hide an unused export. Barrels still cost you elsewhere: every file that imports ./utils depends on everything the barrel re-exports, which slows down bundlers and test runners and creates import cycles between files that never use each other. Barrels and cycles in these same 52 repos are the subject of a later post.

How I got these numbers

The cohort is 195 of the most-starred public repositories indexed on repowise (1,000+ GitHub stars each, 253,688 production source files, November 2026). Dead-code findings are repowise's engine findings at confidence 0.4 and above, counted on production files only, with each repo measured at its own latest index between May and November 2026. The shadcn-ui/ui check was repowise init --yes --no-prose --no-editor-setup (repowise 0.60.1) on a clone at 8ab2771. The Knip runs are Knip 6.44.2 on Node 22.19, on a clone of yamadashy/repomix at 758c3d7 with its own dependencies and its own TypeScript (7.0.2) for the tsc runs. I reverted the --fix changes afterwards.

FAQ

What does Knip do?
Knip finds the entry points of a JavaScript or TypeScript project (from package.json, your config and its framework plugins), follows every import from there, and reports files, exports and dependencies that nothing reaches. It sees through barrel files that use export *.

Does Knip work on plain JavaScript?
Yes. Knip handles JavaScript and TypeScript projects, and the same npx knip command works for both.

Can Knip run in CI?
Yes. npx knip exits with code 1 when it finds something, so it fails a CI step as-is. Add a knip.json for scripts and generated code first, or the first runs will fail on false positives.

Circular imports in Python: why every big Python repo has them, and the few that actually break

Raghav Chamadiya — Thu, 12 Nov 2026 13:00:00 +0000

TL;DR

All 51 popular Python repos I checked (1,000+ GitHub stars each) have circular import chains between files; in the median one, 16.4% of production files sit inside one.
A Python circular import only fails with "partially initialized module" when a name is read from a module that has not finished running, such as a module-level from x import y, a base class, or a decorator that runs on import.
Django has a 179-file import cycle and imports fine, because most of its cycles go through imports inside functions or imports used only for type hints.
Fixes, in order: move the shared code to a third module, import the module instead of the name (with from __future__ import annotations), put type-only imports under TYPE_CHECKING, or import inside the function.

This is the error that sends people searching:

ImportError: cannot import name 'User' from partially initialized module 'shop.models' (most likely due to a circular import)

The usual advice is "you have a circular import, remove it". But I used repowise to look at the import graphs of 51 popular Python repositories (1,000+ GitHub stars each), and every single one has circular import chains between its files. In the median repo, 16.4% of production files sit inside one. In Django, one chain links 179 files, and Django imports fine.

So a cycle on its own is not the problem. Below: which cycles actually raise that error, why most do not, and how to fix the ones that do.

Reproduce it

Two modules in a package, each importing a name from the other:

# shop/models.py
from shop.services import send_welcome


class User:
    def __init__(self, email):
        self.email = email

# shop/services.py
from shop.models import User


def send_welcome(user: User):
    print(f"welcome, {user.email}")

# main.py
from shop.models import User
from shop.services import send_welcome

send_welcome(User("a@example.com"))

$ python main.py
Traceback (most recent call last):
  File "D:\devto-scratch\repro\shop\main.py", line 1, in <module>
    from shop.models import User
  File "D:\devto-scratch\repro\shop\shop\models.py", line 1, in <module>
    from shop.services import send_welcome
  File "D:\devto-scratch\repro\shop\shop\services.py", line 1, in <module>
    from shop.models import User
ImportError: cannot import name 'User' from partially initialized module 'shop.models' (most likely due to a circular import) (D:\devto-scratch\repro\shop\shop\models.py)

What happens, step by step:

main.py imports shop.models. Python creates an empty module object, puts it in sys.modules, and starts running models.py from the top.
Line 1 of models.py imports shop.services, so Python pauses models.py and starts running services.py.
Line 1 of services.py asks for User from shop.models. The module exists in sys.modules, but it is still on line 1. User has not been defined yet.

"Partially initialized" means exactly that: the module object exists, its code has not finished running. The cycle is only fatal because a name is read from the half-built module while it is still half built.

How common are circular imports in Python projects?

The 51 Python repos in the set include django, fastapi, airflow, langchain, prefect and paperless-ngx. Looking at file-to-file imports in production code only (tests, generated and vendored code excluded):

51 of 51 have at least one circular import group (a set of 2+ files that can all reach each other through imports).
In the median Python repo, 16.4% of production files sit inside one.
Across all 195 repos in the wider set, covering every language, the median is 9.2%.

To see why they do not break, I took a fresh clone of Django (commit 6a8248f) and looked at its import graph. Counting every import between the 900 non-test .py files under django/, 238 files sit inside a circular group and the largest group holds 179 files (the whole-repo index counts more, because it also includes files outside django/), from django/__init__.py through apps, conf, db and parts of contrib.

Then I dropped two kinds of import edges: imports written inside a function, and imports used only for type hints. Those two kinds do not run when the module is first loaded. The result:

Django, files under `django/`	Circular groups	Files inside a group	Largest group
All imports	14	238	179 files
Only imports that run at module load	8	58	35 files

Removing 152 import edges, about 5% of the total, shrinks the files involved by three quarters. Most of Django's cycles exist only because some function, somewhere, imports something when it is called. By then every module has finished loading, so there is nothing half built to trip over. Django's code is explicit about it. django/db/models/query_utils.py has this inside Q.check():

        # Avoid circular imports.
        from django.db.models import Value
        from django.db.models.sql import Query
        from django.db.models.sql.constants import SINGLE

git grep -i "circular import" -- 'django/*.py' finds 16 comments like that in 11 files.

The 35-file group that remains is django/db/models, and it survives import because of ordering. django/db/models/__init__.py re-exports names from its submodules, and the order of those imports is pinned:

# Imports that would create circular imports if sorted
from django.db.models.base import DEFERRED, Model  # isort:skip
from django.db.models.fields.related import (  # isort:skip
    ForeignKey,
    ForeignObject,
    OneToOneField,

So the real picture of a big Python codebase is: lots of cycles, nearly all of them harmless, and a handful held together by import order. The error shows up when someone reorders those imports or adds a new module-level import in the wrong direction.

Which circular imports raise "partially initialized module"?

1. A module-level `from x import y` that runs while `x` is half built

That is the reproduction above. from module import name reads the name immediately. If module is still running higher up the stack, the name does not exist yet.

2. Inheriting from a class across the cycle

A class statement needs its base class at the moment the class is created, so even "import the module, not the name" does not save you:

# plugins/base.py
from plugins.email import EmailNotifier


class Notifier:
    def send(self, msg):
        raise NotImplementedError


DEFAULT = EmailNotifier

# plugins/email.py
import plugins.base as base


class EmailNotifier(base.Notifier):
    def send(self, msg):
        print("email:", msg)

  File "D:\devto-scratch\repro\inherit\plugins\email.py", line 4, in <module>
    class EmailNotifier(base.Notifier):
                        ^^^^^^^^^^^^^
AttributeError: partially initialized module 'plugins.base' from 'D:\devto-scratch\repro\inherit\plugins\base.py' has no attribute 'Notifier' (most likely due to a circular import)

3. Registries and decorators that run on import

The classic web-app layout: app.py imports the views so the routes get registered, and views.py imports app to use its decorator.

# web/app.py
from web import views  # load the routes


class App:
    def __init__(self):
        self.routes = {}

    def route(self, path):
        def register(fn):
            self.routes[path] = fn
            return fn
        return register


app = App()

# web/views.py
from web.app import app


@app.route("/")
def index():
    return "hello"

  File "D:\devto-scratch\repro\registry\web\views.py", line 1, in <module>
    from web.app import app
ImportError: cannot import name 'app' from partially initialized module 'web.app' (most likely due to a circular import) (D:\devto-scratch\repro\registry\web\app.py)

The decorator runs at import time, so it needs app before app.py has created it.

How do you fix a circular import in Python?

All of these were run on Python 3.13.

Move the shared piece to a third module

The best fix removes the cycle. In the inheritance example, base.py only imported EmailNotifier to set a default. Move the default somewhere that sits above both:

# plugins/base.py
class Notifier:
    def send(self, msg):
        raise NotImplementedError

# plugins/defaults.py
from plugins.email import EmailNotifier

DEFAULT = EmailNotifier

$ python main.py
email: hi

Now base imports nothing, email imports base, defaults imports email. The arrows only point one way. For the registry example the same idea is an app factory, or a main.py that imports app first and views second.

Import the module, not the name, and defer annotations

from shop import models binds the module object, which exists even while it is half built. You then read models.User later, when it exists. One catch: annotations are evaluated when the function is defined, so this still fails on Python 3.13:

# shop/services.py
from shop import models


def send_welcome(user: models.User):
    print(f"welcome, {user.email}")

    def send_welcome(user: models.User):
                           ^^^^^^^^^^^
AttributeError: partially initialized module 'shop.models' from 'D:\devto-scratch\repro\shop\shop\models.py' has no attribute 'User' (most likely due to a circular import)

Add from __future__ import annotations at the top of services.py and it runs, because annotations become strings that are never evaluated at import time. (Python 3.14 defers annotation evaluation by default, PEP 649.)

If the import is only for type hints, use `TYPE_CHECKING`

# shop/services.py
from __future__ import annotations

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from shop.models import User


def send_welcome(user: User):
    print(f"welcome, {user.email}")

$ python main.py
welcome, a@example.com

The import only exists for mypy, pyright and your editor. At runtime it never executes.

Import inside the function

# shop/models.py
class User:
    def __init__(self, email):
        self.email = email

    def welcome(self):
        from shop.services import send_welcome
        send_welcome(self)

This is what Django does in those 16 commented places. It works, and it is fine as a local patch. It is also how a codebase ends up with a 179-file cycle that nobody can see, so leave a comment, like Django does, saying why the import is there.

How do you find circular imports in your own project?

For a list in the terminal, pylint has a check for exactly this:

pylint --disable=all --enable=cyclic-import django/db

On Django's django/db it reported 72 cyclic-import messages in 8.5 seconds, for example:

django\db\models\sql\__init__.py:1:0: R0401: Cyclic import (django.db.models.manager -> django.db.models.query) (cyclic-import)
django\db\models\sql\__init__.py:1:0: R0401: Cyclic import (django.db.models.base -> django.db.models.fields.related) (cyclic-import)

pylint counts imports inside functions too, so expect it to list cycles that never fail at runtime. pydeps yourpackage --show-cycles draws the same cycles as a graph (it needs Graphviz installed). To stop new cycles in CI, import-linter can fail the build on cycles between subpackages. The setup for that, plus the TypeScript and Go equivalents, is in this guide to finding circular dependencies.

To look at the cycles on a picture instead of a list, Django's architecture view shows the same import graph, and the trace tool on that page finds the path between any two files.

How I got these numbers

The 51 repos are the Python part of a set of 195 of the most-starred public repositories indexed on repowise (1,000+ GitHub stars each, 253,688 production source files, November 2026), each measured at its own latest index between May and November 2026. The cross-language numbers are in finding 6 of the code health 2026 report. Cycles are counted on file-to-file imports between production files, so __init__.py re-exports count as edges. The Django breakdown comes from repowise init --yes --no-prose --no-editor-setup on a fresh clone at 6a8248f, then a strongly connected components pass over the stored import graph, once with every import edge and once without the edges marked as function-level or type-only.

FAQ

What does "partially initialized module ... most likely due to a circular import" mean?
Python has created the module object and put it in sys.modules, but the module's code is still running further up the import chain. Something asked for a name that the module has not defined yet, so the import fails with that message.

Does from __future__ import annotations fix circular imports?
Only when the cycle breaks on a type hint. It turns annotations into strings that are not evaluated at import time, so def f(user: models.User) stops failing. It does not help when the name is needed while the module loads, such as a base class or a decorator.

Are circular imports always a bug in Python?
No. All 51 Python repos in this set have circular import chains between files and import fine. A cycle only fails when one module reads a name from another before that module has finished running.

Python dead code: what 51 popular Python repos ship that nothing imports

Raghav Chamadiya — Wed, 11 Nov 2026 13:00:00 +0000

TL;DR

45 of 50 popular Python repos (1,000+ GitHub stars) have at least one dead-code finding in production code, and in the median repo 3.9% of production files are flagged as unreachable.
In Python, a file nothing imports is often loaded by name: 82 of Django's 100 dead-code candidates are locale files imported from a string at runtime.
814 of the 819 files flagged in LangChain are compatibility shims that keep old import paths working for its users.
vulture finds unused names inside a file and an import-graph pass finds whole files nothing imports; Python projects need both, plus a string search before each delete.

I ran a dead-code pass with repowise over 51 popular Python repositories, each with 1,000+ GitHub stars: Django, FastAPI, Airflow, LangChain, Prefect, paperless-ngx and 45 more. Then I took three of them, cloned them fresh, and read the flagged files one group at a time to see what they really were.

The short version: almost every popular Python repo has code that nothing imports, and in Python "nothing imports this" very often means "something loads this by name". Below are the numbers, what the hand check found, and a way to clean up your own project that takes both facts into account.

What counts as dead code in Python?

Two kinds of finding, on production source files only (tests, generated code, vendored code, build scripts and docs examples are excluded):

A file flagged as unreachable: no other file imports it, and it is not an entry point.
An unused export: a public function, class or constant defined in one module that no other module imports.

Each finding has a confidence between 0 and 1. I call 0.7 and above "high confidence".

How much dead code do popular Python projects carry?

Dead-code data exists for 50 of the 51 Python repos.

45 of 50 have at least one finding. 45 of 50 have at least one unused export, 42 have at least one file flagged as unreachable, and 37 have at least one high-confidence finding.
The median repo has 15.7 findings per 100 production files, and 3.9% of its production files are flagged as unreachable.
Pooled across the 50 repos: 4,074 flagged files and 6,008 unused exports, in 38,285 production files.

Some recognisable names, each measured at its own latest index:

Repo	Production files	Files flagged unreachable	Unused exports	Indexed
fastapi/fastapi	52	0	0	2026-11-04
tobymao/sqlglot	185	0	2	2026-10-26
litestar-org/litestar	325	6	1	2026-11-10
paperless-ngx/paperless-ngx	443	13	8	2026-10-15
django/django	870	154	73	2026-07-29
PrefectHQ/prefect	2,281	153	166	2026-07-17
apache/airflow	4,387	424	556	2026-08-19
langchain-ai/langchain	1,714	819	2	2026-11-04

FastAPI's own package has no findings at all (the table counts production files only). When I re-ran it on a fresh clone, all 259 candidates were in docs_src/ (the code samples behind its documentation), scripts/ and docs/, none in fastapi/.

The bottom rows are where it gets interesting, because what a flagged file means depends on how the project loads its code. Here is what the flagged files were.

What I found when I checked by hand

I cloned each repo, indexed it with the repowise CLI, listed the findings, and then read the flagged files in groups.

Django: 82 of 100 candidates are locale files loaded by string

On Django at commit 6a8248f, the dead-code pass returned 100 candidates. 82 of them are files like these:

django/conf/locale/ar/formats.py
django/conf/locale/ar_DZ/formats.py
django/conf/locale/az/formats.py

No Python file imports django/conf/locale/ar/formats.py. Django loads it at runtime, by building the module name as a string, in django/utils/formats.py:

    for location in format_locations:
        for loc in locales:
            try:
                yield import_module("%s.formats" % (location % loc))
            except ImportError:
                pass

Delete one of those files and Arabic date formatting silently falls back to the default. The other 18 candidates were eight JavaScript files (the admin's static scripts and a JS template, served to the browser), the Sphinx config, extensions and docs linter under docs/, and three functions in scripts/manage_translations.py that its command-line parser dispatches to.

These are files to keep, and the tool treats them that way. Asking for deletion-ready findings only returns nothing, with the reason:

$ repowise dead-code --safe-only
100 finding(s), none deletion-ready: a finding is deletion-ready only when missing imports are evidence for its language. Review the ranked list without the safe-only filter.

LangChain: 814 files that keep old import paths working

On LangChain at commit 1a41b51, 819 files are flagged as unreachable, and 814 of them sit in one package: libs/langchain/langchain_classic. Nearly all look like this:

from typing import TYPE_CHECKING, Any

from langchain_classic._api import create_importer

if TYPE_CHECKING:
    from langchain_community.agent_toolkits.jira.toolkit import JiraToolkit

# Create a way to dynamically look up deprecated imports.
# Used to consolidate logic for raising deprecation warnings and
# handling optional imports.
DEPRECATED_LOOKUP = {"JiraToolkit": "langchain_community.agent_toolkits.jira.toolkit"}

_import_attribute = create_importer(__package__, deprecated_lookups=DEPRECATED_LOOKUP)


def __getattr__(name: str) -> Any:
    """Look up attributes dynamically."""
    return _import_attribute(name)

That is a compatibility shim. Code written against an older LangChain still does from langchain.agents.agent_toolkits.jira.toolkit import JiraToolkit, and this file forwards the import to its new home with a deprecation warning. Nothing inside the repo imports it because the importers are LangChain's users.

I sorted all 819 by what they contain: 758 use create_importer like the file above, 48 only re-export names. Of the remaining 13, nine are importable modules of the same package (prompt templates and API documentation strings), two are version.py files kept for backwards compatibility in partner packages, and two sit in an examples folder. Removing any of the package files is a breaking change for users, not a cleanup.

Across the whole repo, one finding is marked ready to delete: an example function, run_calculator_http, that git grep finds nowhere except its own definition.

Airflow: example DAGs, docs configs, and one repeated helper

On Airflow at commit 6a8bc716, the pass returned 791 candidates: 352 flagged files, 436 unused exports and 3 unused workspace packages. I sorted the 352 files:

111 are example DAGs under example_dags/ folders. Airflow never imports them. It points its DAG processor at the folder and parses every file in it, in airflow-core/src/airflow/dag_processing/bundles/manager.py:

def _add_example_dag_bundle(bundle_config_list: list[_ExternalBundleConfig]):
    from airflow import example_dags

    example_dag_folder = next(iter(example_dags.__path__))

109 are docs/conf.py files, one Sphinx config per provider package. Sphinx loads them by path.
14 are generated OpenAPI client files for the web UI, and most of the rest are other front-end and dev tooling files.
59 are copies of a small version_compat.py helper from the provider package template. In those 59 providers, git grep finds nothing that imports it, so they are the ones worth a look: a few lines each, ready for whenever a provider needs the version check.

So most of Airflow's flagged files are loaded from a folder or by a tool, the same shape as the other repos, and the clear candidates come down to one small template file.

The pattern

In all three, most of the files an import graph cannot reach were reached another way:

by a module name built from a string (import_module, __import__, Django's INSTALLED_APPS, Celery task names), or a folder scanned at runtime (Airflow's DAG folders),
by packaging metadata (console scripts and plugin entry points in pyproject.toml),
or by code outside the repo (a published library's public import paths).

That is why a good dead-code pass for Python reports confidence and a separate "ready to delete" decision, and why the second step is always a search for the module's dotted name as a string.

Vulture or an import graph: what does each one find?

The tool most Python developers know is vulture. It reads each file's syntax tree and reports names that are defined and never used. On the same Django clone:

$ vulture django/ --min-confidence 80
django\contrib\admindocs\middleware.py:14: unused variable 'view_args' (100% confidence)
django\contrib\admindocs\middleware.py:14: unused variable 'view_kwargs' (100% confidence)
django\contrib\auth\middleware.py:54: unused variable 'view_args' (100% confidence)
django\contrib\auth\middleware.py:54: unused variable 'view_kwargs' (100% confidence)
django\contrib\gis\management\commands\ogrinspect.py:14: unused variable 'option_string' (100% confidence)
django\contrib\gis\management\commands\ogrinspect.py:28: unused variable 'option_string' (100% confidence)
django\core\serializers\xml_serializer.py:506: unused variable 'has_internal_subset' (100% confidence)
django\core\serializers\xml_serializer.py:510: unused variable 'is_parameter_entity' (100% confidence)
django\db\backends\utils.py:94: unused variable 'ignored_wrapper_args' (100% confidence)
django\db\backends\utils.py:107: unused variable 'ignored_wrapper_args' (100% confidence)
django\db\models\enums.py:78: unused variable 'last_values' (100% confidence)
django\utils\inspect.py:138: unused variable 'annotation_format' (100% confidence)

Every one of these is a parameter the function has to keep: a callback signature, an overridden method, or a keyword kept for API compatibility. process_view(self, request, view_func, view_args, view_kwargs) has to accept view_args even if this middleware never reads it. At vulture's default threshold of 60%, the same run prints 2,010 lines, mostly unused variables, methods and classes that Django's own machinery or its users call.

The two checks answer different questions:

	vulture	Import-graph pass
Unit	a name inside a file	a whole file, or a name other modules should import
Good at	dead branches, leftover variables, unused private helpers	modules nothing reaches, exports nobody imports
Blind spot	names used by frameworks through reflection	files loaded by string or from outside the repo

Use both. They rarely flag the same thing.

How do you find dead code in a Python project?

Start with vulture at a high threshold, and keep a whitelist for the framework hooks it cannot see:

pip install vulture
vulture src/ --min-confidence 80
vulture src/ --make-whitelist > whitelist.py   # review it, then:
vulture src/ whitelist.py --min-confidence 80

Then look at whole files and exports. With the repowise CLI, which builds the import graph locally and needs no API key:

pip install repowise
repowise init --yes --no-prose --no-editor-setup
repowise dead-code --min-confidence 0.7
repowise dead-code --safe-only

For every file on that list, before deleting it, search for its dotted module name and its file stem as strings:

$ git grep -n "django.conf.locale" -- 'django/*.py'
django/utils/formats.py:76:    format_locations.append("django.conf.locale.%s")
django/utils/translation/__init__.py:270:    from django.conf.locale import LANG_INFO
django/utils/translation/trans_real.py:14:from django.conf.locale import LANG_INFO

If anything builds the name dynamically, you will usually find the prefix, as in the first line here. Search pyproject.toml and setup.cfg too, for entry points.

What I would delete first

Files that are flagged, have no string reference anywhere, and have not changed in a long time. Old and unreferenced is the safest combination.
Unused private helpers vulture finds at 80% or more inside files you already own. Low risk, small diffs.
Nothing in a published package's import surface until a major version. Move it behind a deprecation warning first, the way LangChain does.

Delete in small pull requests, one directory or one kind of finding at a time. Run the full test suite on each, plus an import of every module in the package, which catches a deleted file that something still imports by name at load time:

python -c "import importlib, pkgutil, mypkg; [importlib.import_module(m.name) for m in pkgutil.walk_packages(mypkg.__path__, 'mypkg.')]"

If you are choosing a tool, this comparison of dead code detection tools covers vulture, the import-graph approach and the options for other languages. Django's code health page shows the dead-code list from the table above in the browser.

Which loading pattern has bitten you when deleting "unused" Python code: string imports, entry points, or something else?

How I got these numbers

The 51 repos are the Python part of a set of 195 of the most-starred public repositories indexed on repowise (1,000+ GitHub stars each, 253,688 production source files, November 2026); the dead-code numbers for the full set are in the code health 2026 report. Findings are counted at confidence 0.4 and above, on production files only, with each repo measured at its own latest index between May and November 2026, so the table is a snapshot per repo. The hand checks were fresh clones on 10 November 2026: Django 6a8248f (full history), LangChain 1a41b51 and Airflow 6a8bc716 (last 300 commits), FastAPI ba5d72b (last 500 commits), each indexed with repowise init --yes --no-prose --no-editor-setup (repowise 0.60.1), plus vulture 2.16 on Django. A fresh run can differ from the table, because the code and the tool both move between index dates.

FAQ

What does vulture do in Python?
vulture reads each file's syntax tree and reports functions, classes, variables and imports that are defined and never used, each with a confidence score. It works on names, so it does not report a whole module that nothing imports, and it cannot see names that a framework calls through reflection.

Does Ruff find dead code?
Ruff finds unused imports (F401) and unused local variables (F841) inside each file, and commented-out code with its eradicate rules (ERA001). It does not track whether another module ever uses a function or file, so unused exports and unreachable files need vulture or an import-graph tool.

How do I find unreachable code in Python?
For statements that can never run, such as code after a return, pylint reports unreachable (W0101). For whole files that nothing reaches, build the import graph (for example repowise dead-code --min-confidence 0.7), then search for each file's dotted module name as a string before deleting it, because Python code is often loaded by name.

DEV Community: repowise

Bus factor 1 is the default: per-language ownership in 195 popular repos

How do you calculate bus factor?

Compute it for one file

How common is a bus factor of 1 in open source?

Are the most-changed files single-owner?

What should you do about a bus factor of 1?

How I got these numbers

FAQ

TypeScript unused exports: what 52 popular TS repos carry, and how to clean yours with Knip

How many unused exports do popular TypeScript repos have?

How do you use Knip?

Why doesn't tsc catch unused exports?

Clean up in the right order

How do you configure Knip for a real project?

Barrel files

How I got these numbers

FAQ

Circular imports in Python: why every big Python repo has them, and the few that actually break

Reproduce it

How common are circular imports in Python projects?

Which circular imports raise "partially initialized module"?

1. A module-level from x import y that runs while x is half built

2. Inheriting from a class across the cycle

3. Registries and decorators that run on import

How do you fix a circular import in Python?

Move the shared piece to a third module

Import the module, not the name, and defer annotations

If the import is only for type hints, use TYPE_CHECKING

Import inside the function

How do you find circular imports in your own project?

How I got these numbers

FAQ

Python dead code: what 51 popular Python repos ship that nothing imports

What counts as dead code in Python?

How much dead code do popular Python projects carry?

What I found when I checked by hand

Django: 82 of 100 candidates are locale files loaded by string

LangChain: 814 files that keep old import paths working

Airflow: example DAGs, docs configs, and one repeated helper

The pattern

Vulture or an import graph: what does each one find?

How do you find dead code in a Python project?

What I would delete first

How I got these numbers

FAQ

1. A module-level `from x import y` that runs while `x` is half built

If the import is only for type hints, use `TYPE_CHECKING`