Fix collection of short paths on Windows

[nicoddemus]

Passing a short path in the command line was causing the matchparts check to fail, because Path(short_path) != Path(long_path).

Using os.path.samefile as fallback ensures the comparison works on Windows when comparing short/long paths.

Fix #11895

[nicoddemus]

The initial commit was used just to demonstrate the failing test on CI, however we should squash/merge this in the end.

[bluetech]

Each call to samefile adds 2 stats, and stats are generally reputed to cause slowness. I wonder then, is it possible in Python to "expand" a short path to a long path, then we can run it on the inputs and proceed as usual, instead of using samefile?

[nicoddemus]

I wonder then, is it possible in Python to "expand" a short path to a long path, then we can run it on the inputs and proceed as usual, instead of using samefile?

Should be possible, I will look into it, however I think it will change the resulting node ids.

[nicoddemus]

Done, it was a bit more code but definitely won't impact performance.

[nicoddemus]

@bluetech just stumbled into this:

pytest/src/_pytest/pathlib.py

Lines 595 to 605 in 7690a0d

	# Implement a special _is_same function on Windows which returns True if the two filenames
	# compare equal, to circumvent os.path.samefile returning False for mounts in UNC (#7678).
	if sys.platform.startswith("win"):
	def _is_same(f1: str, f2: str) -> bool:
	return Path(f1) == Path(f2) or os.path.samefile(f1, f2)
	else:
	def _is_same(f1: str, f2: str) -> bool:
	return os.path.samefile(f1, f2)

This suggests we might be not considering other cases if we try to just expand the short names during collection. Perhaps we should bite the bullet and just go with the stat solution? Less code and will be the safest one, while I understand there's the performance concern.

[nicoddemus]

@bluetech what do you think regarding my last point?

[bluetech]

@nicoddemus I'll try to make an informed review, but if I take too long (like before 8.0.2) then please don't wait for me, I don't mean to block this.

[nicoddemus]

I used https://github.com/nicoddemus/collection-test-bed to measure the performance so we can have some numbers to decide.

Using that configuration we have 10.5k tests 4 levels deep, with test files containing simple parametrized tests, here are the numbers in my Windows using pytest --co:

branch	timing
main	8.71s
stat solution	9.23s
convert to long solution	8.70s

So indeed the stat call has some performance penalty, as expected. Keep in mind however that this is for a test suite which does not import anything else, it only imports pytest itself.

Testing in a more realist test suite from a project I have around with 1.3k tests, I couldn't measure any difference between the stat aproach and main, both clocking around the same 6.6s for the full collection.

So while we can see some difference in a synthetic test suite, with 10k tests but without any other imports, using a realistic test suite, with 1.3k tests and which imports application code, the difference is not perceptible at all.

I'm leaning towards the stat solution as it is simpler and also more correct in my opinion.

[Zac-HD]

Looks good, and I also favor the stat solution - correctness is definitely worth it IMO.

[nicoddemus]

Going ahead and merge this then, we can revisit later if needed. 👍