A simple (and fast) requirements.txt file generator
The preqs project is a cross-platform, simple, fast and easy-to-use requirements file generator. Your project's imported dependencies are collected into a requirements.txt file. No more, no less.
Installation
Installing preqs is quick and easy. As a design feature, the library does not have any external (non-built-in) dependencies.
pip install preqs
Usage
The help (or usage) menu can be displayed, as below, using the following command from the terminal:
preqs --help
Which displays:
usage: preqs [PATH] [options]
A simple (and fast) requirements.txt file generator.
positional arguments:
PATH Path to the project's root directory.
Alternatively, the path where the search for modules should start.
Defaults to the current directory.
options:
-c, --check Perform requirements.txt file version checks against the installed
libraries, then exit.
-d, --debug Print verbose debugging output while processing.
-i IGNORE_DIRS [IGNORE_DIRS ...], --ignore_dirs IGNORE_DIRS [IGNORE_DIRS ...]
One or more director(y|ies) to be ignored when collecting module files.
-p, --print Print the detected requirements, rather than creating a file.
-r, --replace Replace the current requirements.txt file.
-h, --help Display this help and usage, then exit.
-v, --version Display the version and exit.
Copyright (C) 2024-2025 | 73rd Street Development
This program comes with ABSOLUTELY NO WARRANTY. This is free
software; you can redistribute it and/or modify it under the terms
of the GNU General Public License as published by the Free Software
Foundation. A copy of the license is included with this
package.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
preqs <installed version>
Usage Example
In its simplest form, preqs can be run by just calling the program from within your project's root directory, without any arguments. The path from which the Python module discovery begins defaults to the current directory. If your project is in another directory, pass that directory's path into the PATH argument. The requirements file is saved into the path provided.
Notes:
- The following examples assume you are already in your project's root directory, therefore
PATHis not provided. - Any of the following flags may be combined to form your own requirements cocktail.
Case 1: Simplest form
Simply generate a requirements file for your project, as:
- Run
preqsas:
preqs
- Check the current directory for a
requirements.txtfile containing the project's external dependencies.
Case 2: Ignoring directories
If you wish to exclude a directory (or directories) from the requirements file, the --ignore_dirs flag may be used as:
- Run
preqsas:
preqs --ignore_dirs docs build
- Check the current directory for a
requirements.txtfile containing the project's external dependencies.
Case 3: Display only (do not generate a file)
In some cases, for example with an existing requirements file you do not want to overwrite, you may wish to display the requirements to the terminal. This can be accomplished using the --print flag, as:
- Run
preqsas:
preqs --print
- Watch the terminal for an output displaying the project's requirements.
Case 4: Overwrite an existing requirements file
By default, if a requirements.txt file exists, you will be alerted. The existing file will not be overwritten. That is, unless you tell preqs it's OK.
- Run
preqsas:
preqs --replace
- Check the current directory for a new
requirements.txtfile containing the project's external dependencies.
Case 5: Check a requirements file against the installed libraries
The --check argument can be used to perform a version check between a requirements file and the installed libraries.
- If
preqsis run as follows, therequirements.txtfile in the current directory is used:
preqs --check
Alternatively, the path to any requirements file can be specified in the path as:
preqs ~/Desktop/requirements.txt --check
This will output a report similar to the following, showing the status of each requirements file entry relative to the installed libraries:
Name Requirement Installed Status
-----------------------------------------------------------------
beautifulsoup4 4.13.4 n/a Not installed
colorama 0.4.6 n/a Not installed
ipython 8.31.0 8.30.0 Older
spyder-kernels 3.0.1 3.0.2 Newer
jupyter_client 8.6.3 8.6.3 Same
requests 2.32.3 n/a Not installed
Additional information
How is the version number obtained?
The version number you see in the requirements file output is obtained using the built-in importlib library. Therefore, the package must be installed in the environment being used to run preqs.
- By design, we do not use PyPI to obtain version numbers as this practice usually involves assuming the latest version - whereas this may not be the case for your project.
- Any packages which are known to be imported by the project, and yet do not appear in the requirements file, are likely not installed in the environment. Run
preqswith the--printflag to observe any packages which are imported for which the version number could not be obtained. These 'unknown version' packages are (currently) ignored when the requirements file is written.
I don't see a specific package in the requirements file.
Refer to the How is the version number obtained? question.
Why should I not just use pip freeze?
Many online 'tutorials' for generating a requirements file say to use pip freeze and redirect the output to a file called requirements.txt. However, this is not good practice for the following reasons:
- All of the packages installed in your development environment will be listed in the requirements file. This may include some (or many) packages which your project does not require, thus bloating the end-user's installation and thereby cluttering their environment. Or, the packages you have in your environment, although not used by the project, may be out-of-date; causing the end-user to be forced to install out-of-date packages.
- A true requirements file should contain only those packages which are imported and required by the project.
- Only the packages that were installed with
pip installwill be included in the requirements file.
Metadata
Release files for preqs 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| preqs-0.2.0.tar.gz | 57.7 kB | Without provenance | Details for preqs-0.2.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| preqs-0.2.0-py3-none-any.whl | Python 3 | none | any | Details for preqs-0.2.0-py3-none-any.whl |
Total release size: 91.9 kB
Release files / preqs-0.2.0.tar.gz
| Download URL | preqs-0.2.0.tar.gz |
|---|---|
| Size | 57.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a047d0ac76f08eb00a9bcc4f845c3bb80d2475daffa4e8b539be4c8f80249d1c
|
|
BLAKE2b-256 checksum How to use checksums |
ac98fc5b452a72c78bfc3a1a60063d32651cc4fa60d7aaa7b18049a63f991865
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.0.1 CPython/3.12.7
|
Release files / preqs-0.2.0-py3-none-any.whl
| Download URL | preqs-0.2.0-py3-none-any.whl |
|---|---|
| Size | 34.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
177eb73a7be6b4e50eb0830060858a6c107dac59486d8bcaf2a49f53ef888310
|
|
BLAKE2b-256 checksum How to use checksums |
17b6455b53c864fd0b90a5f16739b7cb6a88117acc129fc4555b70804a32b840
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.0.1 CPython/3.12.7
|
Security for preqs 0.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.