dirty non-editable install with node-and-timestamp leads to timestamp mismatch

[pmeier]

Reproduction

1. git clone https://github.com/Quansight/ragna
2. cd ragna
3. git checkout dca421b40ebd6876b2d71b624ab9689bd113139a
4. conda env create -f environment-dev.yml -n stscm-debug
5. conda activate stscm-debug
6. echo 'random change' >> README.md
7. pip install .

[...]
  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)

The reason we are checking out a specific commit above, is that we "fixed" the issue for us on later commits. Seeing that the difference is only in the timestamp part we just switched from the node-and-timestamp local scheme to node-and-date.

Apologies for the non-minimal reproduction. Since we have a good enough workaround for us, I don't have time to compile this down into something smaller. Just reported in case this of interest for someone else. Feel free to close.

[RonnyPfannschmidt]

based on provided information i consider this is expected and intended behavior

can you outline why you need to change the project a bit more

setting pretend version may be acceptable as well depending on the goal

[pmeier]

can you outline why you need to change the project a bit more

I don't need to. This was just a byproduct of readthedocs.org injecting some stuff into the worktree before building the documentation (see #962).

based on provided information i consider this is expected and intended behavior

If its intended, why does it only happen for the node-and-timestamp local scheme? Running the exact same thing above, but with note-and-date set, installs without issues.

If you compare the two versions in the error message

expected '0.4.0.dev11+gdca421b.d20250116103122'
got      '0.4.0.dev11+gdca421b.d20250116103209'

you see that they only differ in the seconds part of the timestamp. For me that looks like that the version string is created at two different points of the program independently and because they happen a few seconds apart this problem appears. Or when viewed from the other side: the problem does not appear with the note-and-date scheme because the build happened on the same day (although that can fail as well in cringe edge cases).

[RonnyPfannschmidt]

hmm, i wonder if this ought to be considered a pip bug as dynamic version seems to be ignored in its expectations

node and date would fail on transitions of the date

[dseomn]

hmm, i wonder if this ought to be considered a pip bug as dynamic version seems to be ignored in its expectations

I just ran into this bug, and filed pypa/pip#13420 to see if the pip folks think it's a pip bug.

[RonnyPfannschmidt]

we now use the max mtime of the changed file list instead of datetime.now, this should no longer pose an issue