HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
pypa
pip-tools
Python2013–2026
pypa / pip-tools

pip-tools

A set of tools to keep your pinned Python dependencies fresh.

59Distinct people
64Mentions
1Explicit recommenders
8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A set of tools to keep your pinned Python dependencies fresh.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I personally still find Poetry and Pipenv to be a little heavy-handed for my preferred workflows. To that end, pip-tools [1] is what I recommend to those who feel similarly. It…

arusahni used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year64 dated mentions

Observed mentions: 2013-01-28 21:40:52 UTC to 2026-03-19 16:14:21 UTC.

0510152013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC413
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC14113
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC413
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC707
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC606
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC11011
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
pip-tools = pip-compile + pip-sync A set of command line tools to help you keep your pip-based packages fresh, even when you've pinned them. You do pin them, right? (In building your Python application and its dependencies for production, you want to make sure that your builds are predictable and deterministic.) Installation Similar to pip, pip-tools must be installed in each of your project's virtual environments: $ source /path/to/venv/bin/activate (venv) $ python -m pip install pip-tools Note: all of the remaining example commands assume you've activated your project's virtual environment. Example usage for pip-compile The pip-compile command lets you compile a requirements.txt file from your dependencies, specified in either pyproject.toml, setup.cfg, setup.py, or requirements.in. Run it with pip-compile or python -m piptools compile (or pipx run --spec pip-tools pip-compile if pipx was installed with the appropriate Python version). If you use multiple Python versions, you can also run py -X.Y -m piptools compile on Windows and pythonX.Y -m piptools compile on other systems. pip-compile should be run from the same virtual environment as your project so conditional dependencies that require a specific Python version, or other environment markers, resolve relative to your project's environment. Note: If pip-compile finds an existing requirements.txt file that fulfils the dependencies then no changes will be made, even if updates are available. To compile from scratch, first delete the existing requirements.txt file, or see Updating requirements for alternative approaches. Requirements from pyproject.toml The pyproject.toml file is the latest standard for configuring packages and applications, and is recommended for new projects. pip-compile supports both installing your project.dependencies as well as your project.optional-dependencies. Thanks to the fact that this is an official standard, you can use pip-compile to pin the dependencies in projects that use modern standards-adhering packaging tools like Setuptools, Hatch or flit. Suppose you have a 'foobar' Python application that is packaged using Setuptools, and you want to pin it for production. You can declare the project metadata as: [build-system] requires = ["setuptools", "setuptools-scm"] build-backend = "setuptools.build_meta" [project] requires-python = ">=3.9" name = "foobar" dynamic = ["dependencies", "optional-dependencies"] [tool.setuptools.dynamic] dependencies = { file = ["requirements.in"] } optional-dependencies.test = { file = ["requirements-test.txt"] } If you have a Django application that is packaged using Hatch, and you want to pin it for production. You also want to pin your development tools in a separate pin file. You declare django as a dependency and create an optional dependency dev that includes pytest: [build-system] requires = ["hatchling"] build-backend = "hatchling.build" [project] name = "my-cool-django-app" version = "42" dependencies = ["django"] [project.optional-dependencies] dev = ["pytest"] You can produce your pin files as easily as: $ pip-compile -o requirements.txt pyproject.toml # # This file is autogenerated by pip-compile with Python 3.10 # by the following command: # # pip-compile --output-file=requirements.txt pyproject.toml # asgiref==3.6.0 # via django django==4.1.7 # via my-cool-django-app (pyproject.toml) sqlparse==0.4.3 # via django $ pip-compile --extra dev -o dev-requirements.txt pyproject.toml # # This file is autogenerated by pip-compile with Python 3.10 # by the following command: # # pip-compile --extra=dev --output-file=dev-requirements.txt pyproject.toml # asgiref==3.6.0 # via django attrs==22.2.0 # via pytest django==4.1.7 # via my-cool-django-app (pyproject.toml) exceptiongroup==1.1.1 # via pytest iniconfig==2.0.0 # via pytest packaging==23.0 # via pytest pluggy==1.0.0 # via pytest pytest==7.2.2 # via my-cool-django-app (pyproject.toml) sqlparse==0.4.3 # via django tomli==2.0.1 # via pytest This is great for both pinning your applications, but also to keep the CI of your open-source Python package stable. Requirements from setup.py and setup.cfg pip-compile has also full support for setup.py- and setup.cfg-based projects that use setuptools. Just define your dependencies and extras as usual and run pip-compile as above. Requirements from requirements.in You can also use plain text files for your requirements (e.g. if you don't want your application to be a package). To use a requirements.in file to declare the Django dependency: # requirements.in django Now, run pip-compile requirements.in: $ pip-compile requirements.in # # This file is autogenerated by pip-compile with Python 3.10 # by the following command: # # pip-compile requirements.in # asgiref==3.6.0 # via django django==4.1.7 # via -r requirements.in sqlparse==0.4.3 # via django And it will produce your requirements.txt, with all the Django dependencies (and all underlying dependencies) pinned. (updating-requirements)= Updating requirements pip-compile generates a requirements.txt file using the latest versions that fulfil the dependencies you specify in the supported files. If pip-compile finds an existing requirements.txt file that fulfils the dependencies then no changes will be made, even if updates are available. To force pip-compile to update all packages in an existing requirements.txt, run pip-compile --upgrade. To update a specific package to the latest or a specific version use the --upgrade-package or -P flag: # only update the django package $ pip-compile --upgrade-package django # update both the django and requests packages $ pip-compile --upgrade-package django --upgrade-package requests # update the django package to the latest, and requests to v2.0.0 $ pip-compile --upgrade-package django --upgrade-package requests==2.0.0 You can combine --upgrade and --upgrade-package in one command, to provide constraints on the a
Read the full README on GitHub

What Hacker News says

64 sources
I don’t know if this is how pipreqs works, but I’d be concerned about a typo in an import that inadvertently installs a library. I’ve found pip-tools [1] to be a nice middle ground between `pip freeze` and something heavier like poetry. It’s especially helpful in showing you where a library came from, when a library installs other libraries it depends upon. One could still have a typo in their requirements.in file with pip-tools, but changes there are much less frequent than imports in any Python file in your proejcf which could be a daily occurrence in some codebases. [1] https://github.com/jazzband/pip-tools
In Generate pip requirements.txt file based on imports of any project
> Why is the "requirements.txt" file a stupid flat listing of all transitive dependencies with pinned versions? It makes it harder to change library versions even if there are no true conflicts. My friend, here is what you seek: https://github.com/jazzband/pip-tools requirements.txt is flat because it's really the output of `pip freeze`. It's supposed to completely and exactly rebuild the environment. Unfortunately it's far too flexible and people abuse it by putting in only direct dependencies etc. If you're writing packages, you don't need a requirements.txt at all, by the way. Package dependencies (only direct dependencies) live in pyproject.toml with the rest of the package config. requirements.txt (and pip tools) are only for when you want to freeze the whole environment, like for a server deployment.
In Pyenv – lets you easily switch between multiple versions of Python
It's a topic close to my heart since that is one of the key thing that we solve in the OSS project windmill [1], letting users define simple single-file scripts in python/deno/go and handle the dependencies for them. For deno, as the article points out, it's easy, deno has this feature baked in and we just have to deno run the scripts, similar for go where the imports are pretty much a fully qualified pointer to their source and version. For python, we have to do a bit of machinery: we parse the AST, look at the imports, use the heuristics that most import names correspond to their pypi package (we maintain also a list of exception-mappings), pip-compile [2] all the imports, and then get a requirement file that we attach to the script, pip-install it before running the script (then we do a LOT of magic to cache the dependencies so one doe
Read the rest
sn't actually have to install them 99.9% of the time). Note: if you're interested in a collection of single-file scripts to many APIs, that you can just copy-paste and call the main function of, that's what windmill's hub is for [3] [1]: https://github.com/windmill-labs/windmill [2]: https://github.com/jazzband/pip-tools [3]: https://hub.windmill.dev/
In Single-file scripts that download their dependencies
Reproducibility in [Infosec] Software Research requires DevOpSec, which requires: explicit data and code dependency specifications, and/or trusting hopefully-immutable software package archives, and/or securely storing and transmitting crytographically-signed archival (container) images; and then Upgrade all of the versions and run the integration tests with a git post-receive hook or a webhook to an external service dependency not encapsulated within the {Dockerfile, environment.yml/requirements.txt/postBuild; REES} dependency constraint model. With pip-tools, you update the python software versions in a requirements.txt from a requirements.in meta-dependency-spec-file: https://github.com/jazzband/pip-tools#updating-requirements $ pip-compile --upgrade requirements.in $ cat requirements.tct Poetry has an "Expanded dependency spec
Read the rest
ification syntax" but FWIU there's not a way to specify unsigned or signed cryptographic hashes, which e.g. Pipfile.lock supports: hashes for every variant of those versions of packages on {PyPI, and third-party package repos with TUF keys, too}. From https://pipenv.pypa.io/en/latest/basics/#pipenv-lock : $ pipenv lock > pipenv lock is used to create a Pipfile.lock, which declares all dependencies (and sub-dependencies) of your project, their latest available versions, and the current hashes for the downloaded files. This ensures repeatable, and most importantly deterministic, builds "Reproducible builds" of a DVWA Deliberately Vulnerable Web Application is a funny thing: https://en.wikipedia.org/wiki/Reproducible_builds Replication crisis https://en.wikipedia.org/wiki/Replication_crisis : > The replication crisis (also called the replicability crisis and the reproducibility crisis) is an ongoing methodological crisis in which it has been found that the results of many scientific studies are difficult or impossible to reproduce. Because the reproducibility of empirical results is an essential part of the scientific method,[2] such failures undermine the credibility of theories building on them and potentially call into question substantial parts of scientific knowledge. Just rebuilding or re-pulling a container image does not upgrade the versions of software installed within the container. See also: SBOM, CycloneDx, #LinkedReproducibility, #JupyterREES. `podman-pull` https://docs.podman.io/en/latest/markdown/podman-pull.1.html... ~: podman image pull busybox podman pull busybox docker pull busybox podman pull busybox centos fedora ubuntu debian "How to rebuild and update a container without downtime with docker-compose?" https://stackoverflow.com/questions/42529211/how-to-rebuild-... : docker-compose up -d --no-deps --build #[servicename] "Statistics-Based OWASP Top 10 2021 Proposal" https://dzone.com/articles/statistics-based-owasp-top-10-202... awesome-vulnerable-apps > OWASP Top 10 https://github.com/vavkamil/awesome-vulnerable-apps#owasp-to... : > OWASP Juice Shop: Probably the most modern and sophisticated insecure web application And there's a book, an Open Source Official Companion Guide book titled "Pwning Juice Shop": https://github.com/juice-shop/juice-shop#official-companion-... If the versions installed in the book are outdated, you too can bump the version strings in the dependency specs in the git repo and send a PR Pull Request (which also updates the Screenshots and Menu > Sequences and Keyboard Shortcuts in the book&docs); and then manually test that everything works with the updated "deps" dependencies. If it's an executablebooks/, a Computational Notebook (possibly in a Literate Computing style), you can "Restart & Run all" from the notebook UI button or a script, and then test that all automated test assertions pass, and then "diff" (visually compare), and then just manually read through the textual descriptions of commands to enter (because people who buy a Book presumably have a reasonable expectation that if they copy the commands from the book to a script by hand to learn them, the commands as written should run; it should work like the day you bought it for a projected term of many free word-of-mouth years. From https://github.com/juice-shop/juice-shop#docker-container : docker pull bkimminich/juice-shop docker run --rm -p 3000:3000 With podman [desktop], podman pull bkimminich/juice-shop podman run --rm -p 3000:3000 -n juiceshop0
In Vulhub: Pre-Built Vulnerable Environments Based on Docker-Compose
Piptools [1] resolves this by having a requirements.in file where you specify your top level dependencies, doing the lookup and merging of dependency versions and then generating a requirements.txt lock file. Honestly it’s the easiest and least complex of Python’s dependency tools that just gets out of your way instead of mandating a totally separate workflow a la Poetry. [1] https://github.com/jazzband/pip-tools
In Learning Go as a Python Developer: The Good and the Bad
For those of us using "pip-compile" to pin our Python dependencies, you may have run into the limitation that it can't generate a single "requirements.txt" for all needed Python versions / OSes [1]. "pip-compile-cross-platform" is meant to be used exactly like "pip-compile", while providing better results. This allows projects to get the benefits of better pinning logic without having to make the more-significant migration to a tool like "poetry" [2] (which is what "pip-compile-cross-platform" uses under-the-hood ) [1] https://github.com/jazzband/pip-tools#cross-environment-usag... [2] https://github.com/python-poetry/poetry/
In Show HN: Pip-compile-cross-platform Python dependency pinning but cross-platform

Showing the 15 most recent of 64 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.