Build a Python requirements.txt from presets for Django, FastAPI, Flask, data science, ML and LLM stacks. Set ==, ~= or >= pinning, then copy or download.
This generator builds a requirements.txt file from a searchable catalogue of common Python packages, with the version pinning operator you choose applied consistently across every line. Pick a stack preset, add or remove packages, set ==, ~=, or >= per package, then copy the file to your clipboard or download it straight into your project. Everything runs in the browser — no account, no upload, no package index calls.
It is aimed at the moment when you start a project, not the moment you finish one. On a fresh Django service, a FastAPI microservice, a notebook-driven analysis, or an LLM app, the first requirements.txt is nearly always the same handful of packages plus whatever the framework needs to run in production — and it is easy to forget gunicorn or python-dotenv until deployment fails. Presets encode those lists so you start from a working baseline instead of a blank file.
Eight quick-start presets cover the stacks that account for most new Python projects:
Behind the presets sits a searchable catalogue of around fifty popular packages grouped by category — Web Framework, Data Science, AI/ML, Database, HTTP, Testing, CLI, Cloud, Utilities, and Security — each carrying a suggested version and a one-line description. Anything not in the catalogue can be added by hand with the custom name and version fields, so a private or niche dependency is one keystroke away.
Output options let you set the default pinning operator, include or strip the descriptive comments, sort alphabetically, and group the file into commented category blocks. The generated file is written to a live preview pane with a copy button and a download button.
requirements.txt ready to drop at your project root.The operator you pick decides whether your build is reproducible or merely plausible, and the four options behave very differently.
==2.31 is an exact pin. Only that version satisfies it. This is what you want for anything you deploy: the environment that passes CI is bit-for-bit the environment that runs in production. The cost is that security updates never arrive on their own; you have to bump the file deliberately.
~=2.31 is the compatible release operator from PEP 440. It is equivalent to >= 2.31, == 2.* — it accepts later patch and minor releases within the same major series but refuses a major bump. Written with three components, ~=2.31.4 means >= 2.31.4, == 2.31.*, so only the patch digit is free to move. It is the sensible default for a library, where over-pinning forces version conflicts on everyone who depends on you.
>=1.26 is a floor. It states the oldest version whose API you use and permits anything newer, including a major release that removes the function you called. Useful in libraries alongside an explicit upper bound; risky on its own.
No pin at all means whatever the index serves on the day the build runs. That is fine for a throwaway script and unacceptable anywhere a build has to be repeatable.
A worked example. With the compatible-release default, the FastAPI preset renders as:
# Requirements generated by InventiveHQ Requirements Generator # Generated on 2026-08-12
fastapi~=0.109 # Modern async web framework uvicorn pydantic~=2.6 # Data validation using Python type hints httpx~=0.26 # Async-capable HTTP client python-dotenv~=1.0 # Read key-value pairs from .env sqlalchemy~=2.0 # SQL toolkit and ORM alembic
Note that packages carrying no catalogue version emit a bare name — the operator is only appended when a version is present. Switch the default to exact and every ~= becomes ==; untick comments and the trailing # … text disappears.
A requirements.txt generated here is a declaration of intent: the direct dependencies your code imports, at the versions you chose. It is not a lock file. Installing it resolves each transitive dependency freshly, so two installs a month apart can produce different sub-dependency versions even when your file has not changed. For genuinely reproducible builds, install into a clean virtual environment and then capture the full resolved tree:
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pip freeze > requirements.lock.txtKeep both files, and make sure .venv/ is excluded from version control — the gitignore generator has a Python template that covers it along with __pycache__ and build artefacts. The hand-maintained requirements file says what you meant; the frozen one says what you got. Tools such as pip-tools, Poetry, and uv formalise exactly this split, and the file this generator produces is a valid input to all of them.
A related habit worth adopting: split development-only tooling into a separate file. Test runners, linters, and formatters have no business in a production image. Generate the Testing Suite preset, save it as requirements-dev.txt, and install it only in CI and on developer machines — the Dockerfile generator produces a Python image that installs only the production file.
No. It runs entirely offline against a built-in catalogue of packages with sensible versions recorded at the time of writing. Treat those numbers as a starting point and confirm against PyPI before shipping — particularly for fast-moving AI and web packages.
~= and >=?~=2.6 allows newer releases within the same major version but blocks a major bump. >=2.6 allows anything newer including a breaking major release. Use ~= when you want updates without surprises, >= only when you also add an upper bound.
For applications and anything you deploy, yes — exact pins make builds reproducible. For libraries other people install alongside their own dependencies, prefer ~=, because over-tight pins in a library cause unresolvable conflicts downstream.
Yes. Use the Add Custom Package field at the bottom of the catalogue panel: type the distribution name, optionally a version, and it is added with your current default pinning applied.
uvicorn[standard]?The output format renders extras in square brackets after the package name when an extras value is present on the entry. If you need them and they are not shown, add the full string as a custom package name.
No. --hash entries and environment markers such as ; sys_platform == "win32" are not generated. Add them by hand after downloading, or generate hashes with pip-tools if your supply-chain policy requires them.
At the project root, committed to version control, next to your README. Keeping development tooling in a separate requirements-dev.txt keeps production images smaller and their attack surface narrower.
No. Selection, formatting, and file generation all happen in your browser. Nothing is uploaded and nothing is stored. If you also need to pin front-end assets, our SRI hash generator produces subresource integrity hashes for the scripts your Python app serves.
requirements.txt is the standard dependency specification file for Python projects. It lists the Python packages required to run the project, optionally with version constraints, enabling anyone to recreate the exact environment using pip install -r requirements.txt. This file is the Python ecosystem's equivalent of package.json (Node.js) or Gemfile (Ruby).
This tool generates properly formatted requirements.txt files with common packages for various Python project types, including version pinning best practices and dependency grouping.
| Syntax | Meaning | Example |
|---|---|---|
| package | Latest version | requests |
| package==1.2.3 | Exact version | requests==2.31.0 |
| package>=1.2.0 | Minimum version | requests>=2.28.0 |
| package>=1.2,<2.0 | Version range | requests>=2.28.0,<3.0.0 |
| package~=1.2 | Compatible release (~=1.2 means >=1.2,<2.0) | requests~=2.31 |
| package[extra] | With optional dependencies | requests[security] |
| -r other.txt | Include another requirements file | -r base.txt |
| -e ./local-pkg | Editable install from local path | -e ./my-library |
== pins an exact version (flask==2.3.0). = allows compatible releases (flask=2.3.0 allows 2.3.x but not 2.4.0). >= allows any newer version. Use == for reproducible builds, ~= for patch updates, and >= cautiously.
For applications, pin exact versions for reproducibility. For libraries, use ranges to avoid conflicts with other packages. Always use a lock file (pip-tools, poetry.lock) to capture the full dependency tree.
Use pip freeze > requirements.txt. For cleaner output without subdependencies, use pip-compile from pip-tools or pipreqs to scan imports in your code. Poetry users can export with poetry export.
Extras are optional dependencies for specific features. Specify them in brackets: fastapi[all], pytest[dev]. This installs the main package plus additional dependencies for that feature set.