3 ms·

What does this mean for pip-tools' requirements.in, Pipfile.lock, pip constraints.txt, Poetry.lock, pyroject.toml, and uv.lock?

zahlman 2y ago
pyproject.toml is still fundamentally intended to be an input file that describes abstract dependencies for a single package. Lock files describe entire environments, or at least entire change-sets for an environment, and specify everything - pinned versions, including for transitive dependencies, and also hashes and other expectations for the install artifacts. Tools that use custom lock files are at liberty to switch over, and any concerns about migration, backwards compatibility etc. are up to them. Several major tool authors were consulted for the design repeatedly across the discussion thread, over a period of months (and this is just the latest attempt at the design task; the total history is much longer). uv has an issue up already to track implementation: https://github.com/astral-sh/uv/issues/12584 https://github.com/astral-sh/uv/issues/12584
jamesdf 2y ago
I think the plan is to replace all of those. The PEP has buy in from all the major tools.
- zahlman 2y ago
  It does, and that is the plan as far as I can tell. The prior discussion in the thread, as well as the commit history for the PEP (https://github.com/python/peps/commits/main/peps/pep-0751.rst https://github.com/python/peps/commits/main/peps/pep-0751.rs...), shows pretty clear intent to take all of their needs into consideration.
- westurner 2y ago
  It doesn't mention them in alphabetical order.
  - westurner 2y ago
    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-2752209133 https://github.com/regro/cf-scripts/issues/3920#issuecomment... https://github.com/dependabot/dependabot-core/issues/2227#issuecomment-2742305256 https://github.com/dependabot/dependabot-core/issues/2227#is... incl. links to the source of dependabot
notatallshaw 2y ago
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.

zahlman 2y ago

pyproject.toml is still fundamentally intended to be an input file that describes abstract dependencies for a single package. Lock files describe entire environments, or at least entire change-sets for an environment, and specify everything - pinned versions, including for transitive dependencies, and also hashes and other expectations for the install artifacts. Tools that use custom lock files are at liberty to switch over, and any concerns about migration, backwards compatibility etc. are up to them. Several major tool authors were consulted for the design repeatedly across the discussion thread, over a period of months (and this is just the latest attempt at the design task; the total history is much longer). uv has an issue up already to track implementation: https://github.com/astral-sh/uv/issues/12584 https://github.com/astral-sh/uv/issues/12584

jamesdf 2y ago

I think the plan is to replace all of those. The PEP has buy in from all the major tools.

zahlman 2y ago
It does, and that is the plan as far as I can tell. The prior discussion in the thread, as well as the commit history for the PEP (https://github.com/python/peps/commits/main/peps/pep-0751.rst https://github.com/python/peps/commits/main/peps/pep-0751.rs...), shows pretty clear intent to take all of their needs into consideration.
westurner 2y ago
It doesn't mention them in alphabetical order.
- westurner 2y ago
  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-2752209133 https://github.com/regro/cf-scripts/issues/3920#issuecomment... https://github.com/dependabot/dependabot-core/issues/2227#issuecomment-2742305256 https://github.com/dependabot/dependabot-core/issues/2227#is... incl. links to the source of dependabot

notatallshaw 2y ago

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.