Skip to main content

From .in requirement files generate and fix .lock and .unlock files

PyPI status wreck coverage percentage License
last commit to gauge activity Test suite status Quality check status Documentation
Python versions supported implementations
platforms black
downloads GitHub stars
msftcangoblowme on Mastodon

fixes python package requirement files

* Python 3.10 through 3.14, PyPy

new in 0.3.x

pyproject.toml tool.wreck section; tool.wreck.create_pins_unlock config option; remove .in file handling legacy implementation (#17); warn .in includes .lock (#23); remove setuptools and pip in .lock (#35); cower and pay homage to pypi.org cartel (#30); drop py39 support;

new in 0.2.x

compatible release operator support; arbitrary equality issue UnResolvable; add logging-strict and pytest-logging-strict support;

What wreck?

Fix the requirements/constraint files and there would be little or no need to fix venvs

wreck is a homophone (same or similar pronunciation) of req, abbreviated form of requirement. The past tense of wreck is either wrecked or rekt; depending on how old you are.

Generates both lock and unlock requirement files. Fixes both! Minimizing the likelihood of dependency conflicts

Focus is on the requirements and constraints files, venv aware, but not dependent on venv. Not a venv manager.

Caters to authors of apps (lock) and packages (lock and unlock).

Gauge the demand

Frustrating

GIL and multithreading UX aside, resolving dependency conflicts is the next most frustrating issue facing Python coders

multiple venv

Often don’t consider there will be multiple venv, not always just one. So all requirements don’t apply to all venv

Easy learning curve

Configuration read from pyproject.toml. There is one section per venv. Then run one cli command per venv.

Unlike other packages, per .in file, produces two files: .unlock and .lock

For a particular venv, fixes all requirement files, rather than one file at a time

app and package authors

The needs of an app and a package author cannot be solved by a tool that caters only towards app authors

Not automatically resolved

For dependency conflicts, that can’t be automagically resolved, falls into these categories:

  • unresolvable

    pip<24.2 and pip>=24.2 is unresolvable.

    One possible solution is to split requirements into multiple venv

  • shared between multiple venv

    Ideally, code is kept DRY (don’t repeat yourself) as pragmatic. This applies equally to requirements and constraints.

    .shared.in constraints are included into many venv, special care must be taken.

    wreck deals with fixing requirements and constraints which apply to one venv at a time. When applies to multiple venv, wreck supports this, but can’t fix conflicts.

Configuration

In pyproject.toml, for each venv, add a [[tool.venv]] section.

[[tool.wreck.venvs]]
venv_base_path = '.venv'
reqs = [
    'requirements/dev',
    'requirements/kit',
    'requirements/pip',
    'requirements/pip-tools',
    'requirements/prod.shared',
    'requirements/manage',
    'requirements/mypy',
    'requirements/tox',
]

[[tool.wreck.venvs]]
venv_base_path = '.doc/.venv'
reqs = [
    'docs/requirements',
    'docs/pip-tools',
]

These are top most level requirement files without last suffix.

The additional requirements are for use by tox and CI/CD workflows.

  • use posix relative paths

  • assumed the venv are within the package base folder

  • requirements and constraints files are not required to be in a subfolder, however it’s highly encouraged

package author

Possible corresponding dependency section

[tool.setuptools.dynamic]

dependencies = { file = ['requirements/prod.shared.unlock'] }
optional-dependencies.pip = { file = ['requirements/pip.lock'] }
optional-dependencies.pip_tools = { file = ['requirements/pip-tools.lock'] }
optional-dependencies.dev = { file = ['requirements/dev.lock'] }
optional-dependencies.manage = { file = ['requirements/manage.lock'] }
optional-dependencies.docs = { file = ['docs/requirements.lock'] }

Dependencies last suffix is .unlock

apps author

Possible corresponding dependency section

[tool.setuptools.dynamic]
dependencies = { file = ['requirements/prod.shared.lock'] }
optional-dependencies.pip = { file = ['requirements/pip.lock'] }
optional-dependencies.pip_tools = { file = ['requirements/pip-tools.lock'] }
optional-dependencies.dev = { file = ['requirements/dev.lock'] }
optional-dependencies.manage = { file = ['requirements/manage.lock'] }
optional-dependencies.docs = { file = ['docs/requirements.lock'] }

Dependencies last suffix is .lock

Usage

reqs fix --venv-relpath='.venv'
reqs fix --venv-relpath='.doc/.venv'

Provide path to the pyproject.toml if different location from cwd. Either the absolute path to the base folder or the file.

reqs fix --venv-relpath='.venv' --path=~/parent_folder/package_base_folder
reqs fix --venv-relpath='.venv' --path=~/parent_folder/package_base_folder/pyproject.toml

--venv-relpath does not support absolute path

Command options

reqs fix options

cli

default

description

-p/–path

cwd

absolute path to package base folder

-v/–venv-relpath

None

venv relative path. None implies all venv use the same python interpreter version

-t/–timeout

15

Web connection time in seconds

–show-unresolvables

True

For each venv, in a table print the unresolvable dependency conflicts

–show-fixed

True

For each venv, in a table print fixed issues

–show-resolvable-shared

True

For each venv in a table print resolvable issues that involve .shared.in files

Exit codes

0 – Evidently sufficient effort put into unittesting. Job well done, beer on me!

1 – Failures occurred. failed compiles report onto stderr

2 – entrypoint incorrect usage

3 – path given for config file reverse search cannot find a pyproject.toml file

4 – pyproject.toml config file parse issue. Expecting [[tool.wreck.venvs]] sections

5 – package pip-tools is required to lock package dependencies. Install it

6 – Missing some .in files. Support file(s) not checked

7 – venv base folder does not exist. Create it

8 – expecting [[tool.wreck.venvs]] field reqs to be a sequence

9 – No such venv found

10 – timeout occurred. Check web connection

11 – YAML validation unsuccessful for either registry or logging config YAML file

Theory

Current theory

files

file

description

requirements-*.in

might contain pins. Maybe either a requirement or a constraints file

requirements-*.txt

output file consumable by pip

Difference between requirements and constraints

  • constraints files cannot have lines with -e

  • constraints files cannot have lines with extras e.g. coverage[toml]

  • If needed, constraints are applied

wreck theory

The requirements- prefix is noisy, provides no useful info, ugly. It’s use is discouraged.

files

file

description

*.in

raw requirement or constraints file

*.shared.in

constraints file could be shared by more than one venv

*.lock

locked requirement file

*.unlock

unlocked requirement file

There is also *.shared.lock and *.shared.unlock

Document issues in the respective *.in and *.shared.in file. Every undocumented pin is bad UX.

The fixes of each dependency conflict issue should be separated into a pins-*[.shared].in file.

e.g. pins-ccfi.in or pins-myst-parser.in

When the crisis is over. Removed these files along with any links to them.

Market research

packages

package

description

pip-compile-multi

sync multiple calls produces lock files

uv

A venv manager. Offers cli options to resolve conflicts

poetry

venv manager and build backend. Complex config within pyproject.toml

base packages

package

description

pip-tools

does not sync multiple calls

pip

present actionable info. Includes an ugly traceback

not useful

package

description

pyp2req

venv unaware. Fixes nothing.
Prints backend requires and top level dependencies to stdout

No package deals exclusively, effectively, and solely with requirements/constraint files. The top packages, which actual fixes dependency conflicts, are venv managers. Gives options to mitigate issues.

The top packages apply fixes to the venv, not the requirements/constraint files.

If the requirements/constraint files are fixed, there would be little or no need to fix venvs.

If anyone disagrees with these assessments of other packages, create an issue. Recommend a 1-2 line description

Known issues

Any/all known shortcomings are tracked within CHANGES.rst section Known regressions.

Accepted feature requests are tracked within CHANGES.rst section Feature request. There should also be a corresponding issue.

License

aGPLv3+

The short ramifications are:

  • commercial/public entities must obtain a license waiver

Meaning pay to support the project and towards funding ongoing package maintenance.

  • Do not change the copyright notice; that’s serious IP theft.

Release files for wreck 0.3.6.post0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for wreck 0.3.6.post0
File Size Uploaded
wreck-0.3.6.post0.tar.gz 591.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for wreck 0.3.6.post0
File Interpreter ABI Platform
wreck-0.3.6.post0-py3-none-any.whl Python 3 none any Details

Total release size: 698.1 kB

Release files / wreck-0.3.6.post0.tar.gz

Download URL wreck-0.3.6.post0.tar.gz
Size 591.8 kB
Tags Source
SHA-256 checksum
How to use checksums
31854107c4b2654f6c219556946f171dc203b0a64e12a2d93c71ffece5ebc0b6
BLAKE2b-256 checksum
How to use checksums
1484fb5069adc0aa6671dbc20b1bc9279d728f844d2082a95bae2c6433c19dc9
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

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.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 8, 2026.

Transparency log

Release files / wreck-0.3.6.post0-py3-none-any.whl

Download URL wreck-0.3.6.post0-py3-none-any.whl
Size 106.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a7e7c3f297b40a4eb4e7bce4bd6d2b6927e0a7b171168b14ba3219cbdeef0464
BLAKE2b-256 checksum
How to use checksums
7053da8f57562a0d15d5de483c3742f7ac7926f5d358beaf3695a7682536cc83
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

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.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 8, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.3.6.post0 This release

2 release files

0.3.6

2 release files

0.3.5

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page