And it isn’t even written in Python!
That means it can’t be maintained by the community it’s serving. For those skilled in both Rust and Python can understand why it would appear as the best thing since sliced bread.
What about for those not skilled in Rust? Should we also learn 15 other coding languages while we are at it?
wreck is written in Python and manages dependencies. via hierarchy of requirements files, not TOML. It’s venv aware. For Python package authors.
Using the UV hashbang and a few doc strings for dependencies so you can run full on python scripts as executables is fucking crack.
I have an idea of what this might look like, but do you have any examples I can crib from?
This article looks like it explains the process:
https://mathspp.com/blog/til/standalone-executable-python-scripts-with-uv
Does it allow differentiating between dependencies and dev dependencies though? I couldn’t gather that from the article.
it does, I use it every day
this is the standard https://packaging.python.org/en/latest/specifications/dependency-groups/
wreck can. It’s venv aware. Takes full advantage of hierarchical requirement files. Is intuitive. The learning curve is minimal. Written in Python.
[[tool.wreck.venvs]] venv_base_path = '.venv' reqs = [ 'requirements/pip', 'requirements/pip-tools', 'requirements/prod', 'requirements/dev', 'requirements/manage', 'requirements/kit', 'requirements/mypy', 'requirements/tox', ] [[tool.wreck.venvs]] venv_base_path = '.doc/.venv' reqs = [ 'docs/requirements', 'docs/pip-tools', ][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'] }reqs fix --venv-relpath='.venv'reqs fix --venv-relpath='.doc/.venv'From
*.inrequirements files would produce*.unlockand*.lockfiles for venv.venv. Package versions are sync’ed within all requirements files within that venv.






