PEP 751 has been accepted! https://peps.python.org/pep-0751/

This means #Python now has a lock file standard that can act as an export target for all tools that can create some sort of lock file. And for some tools the format can act as their primary lock file format as well instead of some proprietary format.

Also, happy National Indigenous Languages Day in Canada! https://www.canada.ca/en/prairies-economic-development/services/indigenous/national-indigenous-languages-day.html

PEP 751 – A file format to record Python dependencies for installation reproducibility | peps.python.org

This PEP proposes a new file format for specifying dependencies to enable reproducible installation in a Python environment. The format is designed to be human-readable and machine-generated. Installers consuming the file should be able to calculate wha...

Python Enhancement Proposals (PEPs)

@brettcannon

Prefer the simplicity of multiple `requirement-*.txt` files.

Also dependency groups seems like a flawed concept. Don't know which venv the dependency group applies too. Need that context.

-- author of wreck

@msftcangoblowme Are you saying you're the author of 'wreck' or you're just quoting them?

And it's fine if you don't care about the security aspects and want to stick with requirements files, but they aren't a standard and the pip devs wanted something like PEP 751.

And knowing what virtual environment a dependency group is tied to is between you and your workflow tool; dependency groups are entirely orthogonal to virtual environments.

@brettcannon i am the author of wreck. Not just quoting.

For libraries (with unlocked dependencies), not top level apps (locked dependencies), especially multiple venvs and multiple packages, dependencies need to be sync'ed.

The *security aspect* is N/A or a low priority for libraries.

The very real problem of sync'ing dependencies within one package (with multiple venv) and across a chain of packages is never mentioned and not addressed.