"Wheel has unexpected file name" with timestamp in dynamic version

[dseomn]

Description

From https://github.com/pypa/setuptools-scm/issues/1099, when the version is generated dynamically and includes the timestamp, pip fails when the timstamp changes.

Expected behavior

No error when the version includes the timestamp. Maybe that means freezing the version at the beginning, or maybe changing the validation logic, I'm not sure.

pip version

25.1.1

Python version

3.13.3

OS

Debian testing/unstable

How to Reproduce

See https://github.com/pypa/setuptools-scm/issues/1099. Basically, use setuptools_scm's local_scheme = "node-and-timestamp" to include the timestamp in the version.

Output

From https://github.com/pypa/setuptools-scm/issues/1099:

  WARNING: Built wheel for Ragna is invalid: Wheel has unexpected file name: expected '0.4.0.dev11+gdca421b.d20250116103122', got '0.4.0.dev11+gdca421b.d20250116103209'
Failed to build Ragna
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (Ragna)

With the pip/python versions I mentioned in this bug report, and the package I was trying to install:

Processing /home/dseomn/Code/ginjarator
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: ginjarator
  Building wheel for ginjarator (pyproject.toml) ... done
  Created wheel for ginjarator: filename=ginjarator-0.0.post1.dev41+ge5a1d7c.d20250608201500-py3-none-any.whl size=15971 sha256=e51f5ec8f015f98127ff3f423f54c9c3988547f083ac6cae49aa6d7869504ab8
  Stored in directory: /tmp/pip-ephem-wheel-cache-ggcq8uhl/wheels/29/83/4b/0674fb89c41b81442e8a0982cd903d0ab1c84b6c6ad64b305f
  WARNING: Built wheel for ginjarator is invalid: Wheel has unexpected file name: expected '0.0.post1.dev41+ge5a1d7c.d20250608201459', got '0.0.post1.dev41+ge5a1d7c.d20250608201500'
Failed to build ginjarator
ERROR: Failed to build installable wheels for some pyproject.toml based projects (ginjarator)

Code of Conduct

• [x] I agree to follow the PSF Code of Conduct.

[RonnyPfannschmidt]

This one is tricky as it presumes certain details

I wonder if its necessary to consider ctime in setuptools_scm

[pfmoore]

It sounds to me like prepare_metadata_for_build_wheel might be returning a different version than build_wheel - which could be because the version is based on a time (the resolver can take multiple seconds to complete). If that's the case, then it's likely a build backend error, as build_wheel is supposed to respect the metadata directory passed into it (which will have come from prepare_metadata_for_build_wheel).

[RonnyPfannschmidt]

So setuptools_scm needs to ensure its the same

Setuptools doesn't expose the details in any way it can act uppon

[ichard26]

This is a setuptools (or setuptools-scm?) issue as this violates the contract build backends are supposed to follow for prepare_metadata_for_build_wheel() and build_wheel().