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
no support for editable builds
no url support
no hashs
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
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.
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.
... 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.
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
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?