PEP 621 allows for dynamic metadata in pyproject.toml. Tools like setuptools-scm make use of this feature by computing the version of the package at build time.

Imagine I have a git repository with nothing but this pyproject.toml file that is committed.

[build-system]
requires = ["setuptools>=64", "setuptools_scm>=8"]
build-backend = "setuptools.build_meta"

[project]
name = "foo"
dynamic = ["version"]

[tool.uv]
dev-dependencies = [
    "setuptools-scm>=8.1.0",
]

[tool.setuptools_scm]

$ ls -lA
total 8
drwxr-xr-x 8 pmeier pmeier 4096 Aug 30 11:40 .git
-rw-r--r-- 1 pmeier pmeier  238 Aug 30 11:34 pyproject.toml
$ git log --oneline
1105907 (HEAD -> main) initial commit

Running uv sync gives me the following block in uv.lock

[[package]]
name = "foo"
version = "0.1.dev1+g1105907"
source = { editable = "." }

We commit that and move on with development.

$ git add uv.lock
$ git commit -m "add lock" > /dev/null
$ git log --oneline
409a76d (HEAD -> main) add lock
1105907 initial commit

Re-running, uv sync results in no changes in the lock file or venv, although we have

$ uv run python -m setuptools_scm
0.1.dev2+g409a76d

Running uv sync --reinstall-package foo installs the correct version into the venv (checked with uv pip show foo), but again the uv.lock file stays untouched. Even why I manually change the version in the lock file to 0+dynamic (uv complains if the string doesn't start with a number), uv lock does not change the uv.lock file at all.

IMO, in general this is good behavior given that it is impossible to lock the version of this editable package, since its version is computed dynamically. However, I'd prefer not have a quickly outdated version number "hardcoded" in the lock file.

Would it be possible to set the version to "dynamic" (or a different sentinel) if the package is an editable install and declares that the version is computed dynamically?