getlibs

getlibs is a dependency analysis tool that scans every import statement in a Python project and works out where each module comes from. It tells apart the project's own files, modules from Python's standard library and third-party packages installed with pip. Imports that cannot be found anywhere are flagged separately. I wrote the tool in early 2026 and published it on PyPI.

Purpose

When moving a Python project that had grown over the years to another server, or setting it up in a fresh environment, the thing that cost me the most time was not knowing which packages the project actually needed. In most projects the requirements.txt file was either missing or long out of date. Running pip freeze lists everything installed in the environment, so packages the project never used ended up in the file too. I built getlibs to solve this. Its three main goals are generating a requirements.txt that contains only the packages a project really uses, checking dependencies in CI/CD (continuous integration and delivery) pipelines, and checking compatibility across different Python versions.

How it works

The tool starts by probing the target Python interpreter. It runs a small script inside that interpreter and collects three things. The first is the list of standard library modules, taken from sys.stdlib_module_names on newer Python versions and from sys.builtin_module_names on older ones. The second is the set of installed packages and their versions. The third is the mapping between import names and pip package names, read from each package's top_level.txt file. This mapping matters because the name you install a package under is often different from the name you import in code.

Next it walks the project directory and builds a list of local modules from all .py files and every folder that contains an __init__.py. It parses each Python file with Python's own ast module. An AST (abstract syntax tree) is the structured form of the code as the compiler sees it. Because of this, the word "import" inside comments or strings is never counted by mistake; only real import and from ... import statements are considered.

Each import is then checked in order. It looks at local modules first, then the standard library, and finally the installed packages. Imports that match none of these are reported as unknown.

Key features

• It reads imports from the syntax tree instead of using regular expressions.
• It uses each package's top_level.txt to map an import name to the correct pip package.
• It runs the analysis through the interpreter given with --python-exec, so differences between the environment I run the tool in and the one the project will run in do not distort the result.
• It shows local, standard library, third-party and unknown imports separately for every file.
• It lists third-party packages together with their installed version numbers.

Outputs

Each run creates a report folder stamped with the date and time and writes four files into it. The first is a detailed Markdown report, file by file. The second is a JSON report that CI pipelines can read. The third is a requirements.txt containing only the packages used in the project, with their versions. The fourth is a constraints.txt covering every package installed in the environment.

Technical stack

getlibs is written entirely with the Python standard library and has no external dependencies. I use ast for parsing code, subprocess for running the target interpreter, importlib.metadata for reading package information and argparse for command-line options. The package is built with setuptools through pyproject.toml, supports Python 3.9 and later, and is distributed under the MIT license. Installing it adds a command-line tool called getlibs. Changing into the project directory and running getlibs --project-dir . --python-exec python3.13 is all it takes.

Use cases

• I use it to produce a requirements.txt from scratch for an old project that has no dependency list.
• Before moving a project to a new Python version, I run it against the target interpreter to see which packages are not installed there.
• Thanks to the JSON output, a CI pipeline can notice when an import is missing or unknown.
• In a project I have just inherited, I read the detailed report to see quickly which file depends on which external packages.