This is great. pip-tools` is so valuable right now in helping mitigate these dependency tree issues. I'd love to see some form of support in core Python. I really hope this becomes pushed out, similar to how `pip` actually has a dependency resolver now. Relying on running `pip freeze` to create a quasi-lock is a horrible pattern for enterprise environments and for packages. I'm really looking forward to how this turns out, even though it's still in a proposal-type phase. `
What does this mean for pip-tools' requirements.in, Pipfile.lock, pip constraints.txt, Poetry.lock, pyroject.toml, and uv.lock?
A more direct link (should also work for people viewing the Discourse forum in "infinite scroll" mode rather than with pagination): https://discuss.python.org/t/_/77293/150
Very personal nitpick, but I don't like prefixing things with py, it makes no sense to me. A lock is a lock, so why a pylock.toml and not a lock.toml? You do what you want with it. Same with pyproject.toml
It's still a draft, so not officially standardized yet.
PEP 751: https://peps.python.org/pep-0751/