this post was submitted on 16 Feb 2025
5 points (72.7% liked)

Python

6684 readers
4 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

📅 Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
💓 Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
 

Market research

This post is only about dependency management, not package management, not build backends.

You know about these:

  • uv

  • poetry

  • pipenv

You are probably not familiar with:

  • pip-compile-multi

    (toposort, pip-tools)

You are defintely unfamiliar with:

  • wreck

    (pip-tools, pip-requirements-parser)

pip-compile-multi creates lock files. Has no concept of unlock files.

wreck produces both lock and unlock files. venv aware.

Both sync dependencies across requirement files

Both act only upon requirements files, not venv(s)

Up to speed with wreck

You are familiar with .in and .txt requirements files.

.txt is split out into .lock and .unlock. The later is for packages which are not apps.

Create .in files that are interlinked with -r and -c. No editable builds. No urls.

(If this is a deal breaker feel free to submit a PR)

pins files

pins-*.in are for common constraints. The huge advantage here is to document why?

Without the documentation even the devs has no idea whether or not the constraint is still required.

pins-*.in file are split up to tackle one issue. The beauty is the issue must be documented with enough details to bring yourself up to speed.

Explain the origin of the issue in terms a 6 year old can understand.

Configuration

python -m pip install wreck

This is logging-strict pyproject.toml


[tool.wreck]
create_pins_unlock = false

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

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

dynamic = [
    "optional-dependencies",
    "dependencies",
    "version",
]

[tool.setuptools.dynamic]
dependencies = { file = ["requirements/prod.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"] }
version = {attr = "logging_strict._version.__version__"}

Look how short and simple that is.

The only thing you have to unlearn is being so timid.

More venvs. More constraints and requirements complexity.

Do it

mkdir -p .venv || :;
pyenv version > .venv/python-version
python -m venv .venv

mkdir -p .doc || :;
echo "3.10.14" > .doc/python-version
cd .doc && python -m venv .venv; cd - &>/dev/null

. .venv/bin/activate
# python -m pip install wreck
reqs fix --venv-relpath='.venv'

There will be no avoidable resolution conflicts.

Preferable to do this within tox-reqs.ini

Details

TOML file format expects paths to be single quoted. The paths are relative without the last file suffix.

If pyproject.toml not in the cwd, --path='path to pyproject.toml'

create_pins_unlock = false tells wreck to not produce .unlock files for pins-*.in files.

DANGER

This is not for a faint of heart. If you can avoid it. This is for the folks who often say, Oh really, hold my beer!

For pins that span venv, add the file suffix .shared

e.g. pins-typing.shared.in

wreck deals with one venv at a time. Files that span venv have to be dealt with manually and carefully.

Issues

  1. no support for editable builds

  2. no url support

  3. no hashs

  4. your eyes will tire and brains will splatter on the wall, from all the eye rolling after sifting thru endless posts on uv and poetry and none about pip-compile-multi or wreck

  5. Some folks love having all dependency managed within pyproject.toml These folks are deranged and its impossible to convince them otherwise. pyproject.toml is a config file, not a database. It should be read only.

  6. a docs link on pypi.org is 404. Luckily there are two docs links. Should really just fix that, but it's left like that to see if anyone notices. No one did.

all 7 comments
sorted by: hot top controversial new old
[–] FuzzChef@feddit.org 2 points 4 days ago (2 children)

Pipenv deserves to be on your list as well.

[–] logging_strict@programming.dev 1 points 4 days ago* (last edited 4 days ago)

You are right. I added it. Thank you

[–] it_depends_man@lemmy.world 1 points 4 days ago (2 children)

my take on this whole thing is:

... and there it is! A tool to fix the fallout of the practice of always using venvs and always version pinning.

Nice.

I have no need for this kind of tool, because I don't have version conflicts. Does this manage my dependencies in other ways?


No idea what .in is.

.txt is split out into .lock and .unlock.

Are they still .txt or is there a new file standard for .lock and .unlock?

pyproject.toml

.toml,

The only thing you have to unlearn is being so timid.

No, that's... against community rules :) I don't like the common use of venvs or .toml very much and I don't like their use by other people and "timid" is also diplomatic. So you're getting timid, and we get to get along and we can agree to disagree on the use of .venvs and we can wish each other a pleasant day.

No, that’s… against community rules :) I don’t like the common use of venvs or .toml very much and I don’t like their use by other people and “timid” is also diplomatic. So you’re getting timid, and we get to get along and we can agree to disagree on the use of .venvs and we can wish each other a pleasant day.

Think you broke the Internet. That's brilliant /nosarc.

Want you to write my code of misconduct!

I have no need for this kind of tool, because I don’t have version conflicts. Does this manage my dependencies in other ways?

Happily no. wreck attempts to do only one thing. If you don't have version conflicts in your requirements files then whatever you are doing, keep doing that.

No idea what .in is.

requirements-*.in. are placed in folders. So requirements/whatever.in --> requirements/whatever.lock and requirements/whatever.unlock

Are they still .txt or is there a new file standard for .lock and .unlock?

.txt is meaningless or exceedingly broad. A text file huh? Well that explains everything.

The standard is what works.

use of venvs

Containerization, especially for GUIs and apps, is better than depending on venvs. Until it's not. Then still need venvs

Why have you been keeping this a secret?

I have. Wanted to see if anyone would find a published pypi.org package organically, w/o any marketing.

Surely with a trillion eye balls and the super powers of AI, it would be impossible to hide something in plain sight, Right? Especially on the most important topic in Python.

Now the question becomes, does the world+dog ignore federated social media? Is every coder required to have a blog?