Python lock files have officially been standardized
discuss.python.org
Python lock files have officially been standardized
1–10 of 18 posts
Re: Python lock files have officially been standardized
#2PEP 751: https://peps.python.org/pep-0751/
Re: Python lock files have officially been standardized
#3It's still a draft, so not officially standardized yet.
Re: Python lock files have officially been standardized
#4It's still a draft, so not officially standardized yet.
It's only marked as a draft because there has not been a PR to update the status as it was just approved this morning.
Re: Python lock files have officially been standardized
#5What does this mean for pip-tools' requirements.in, Pipfile.lock, pip constraints.txt, Poetry.lock, pyroject.toml, and uv.lock?
Re: Python lock files have officially been standardized
#6What does this mean for pip-tools' requirements.in, Pipfile.lock, pip constraints.txt, Poetry.lock, pyroject.toml, and uv.lock?
I think the plan is to replace all of those.
The PEP has buy in from all the major tools.
Re: Python lock files have officially been standardized
#7Re: Python lock files have officially been standardized
#8Earlier quoted context omitted.
I think the plan is to replace all of those. The PEP has buy in from all the major tools.
It doesn't mention them in alphabetical order.
From last week re: GitHub Dependabot and conda/mamba/micromamba/pixi support:
"github dependabot, meta.yaml, environment.yml, conda-lock.yaml, pixi.lock" https://github.com/regro/cf-scripts/issues/3920#issuecomment... https://github.com/dependabot/dependabot-core/issues/2227#is... incl. links to the source of dependabot
Re: Python lock files have officially been standardized
#9What does this mean for pip-tools' requirements.in, Pipfile.lock, pip constraints.txt, Poetry.lock, pyroject.toml, and uv.lock?
During the, very long, discussion it became apparent that different tools have different design requirements on a lock file. So it's not really clear what will happen to other lock files.
It may be this new lock file acts as an interchange format, that all tools can consume or produce, but not something they internally use.
Though, maybe we're lucky and tools will be able to use it directly, or we might have to wait for a new version of the standard once tools have been able to work with it long enough to know the deficiencies.
Non-lock files, like pyroject.toml and requirements.in remain unaffected.
Re: Python lock files have officially been standardized
#10This 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. `