tests: re-harden test_cmdline_python_package_symlink

[blueyed]

This was done on purpose in 7268462, and then reverted in a non-merge
"Merge" commit (wrong conflict resolution?):
9646a1cd7#diff-1f1fc4eef6bf4c4da558e0dce9e74e9bR761-R762

[nicoddemus]

wrong conflict resolution?

Probably, thanks!

[blueyed]

The Windows behavior in py38 confused me - is it creating only a non-dir symlink there or something?

[blueyed]

So my guess is that this somehow regressed before, but is/was hidden by un-hardening it in two different places (and the initial mixup of checking py.path's attribute, additionally to skipping it etc).
Needs someone with Windows to investigate I guess.

[nicoddemus]

Needs someone with Windows to investigate I guess.

I'm assigning it to myself, thanks again.

[blueyed]

Slightly improved version used in #6733.

[nicoddemus]

Gave this another go, but no luck so far.

It seems that on Linux nodeids are constructed by resolving symlinks, hence we get this output:

lib/foo/bar/test_bar.py::test_bar <- local/lib/foo/bar/test_bar.py PASSED

That output means (nodeid) <- (fspath), built from here:

pytest/src/_pytest/terminal.py

Lines 772 to 775 in f77d606

	if self.verbosity >= 2 and nodeid.split("::")[0] != fspath.replace(
	"\\", nodes.SEP
	):
	res += " <- " + self.startdir.bestrelpath(fspath)

On Windows, nodeid and fspath are the symlink:

local/lib/foo/bar/test_bar.py::test_bar PASSED

I have to find where nodeid turns into a symlink. Will need to investigate more some other time.

[blueyed]

@nicoddemus
The interesting part would be why / if symlinks always (seem) to work on Windows.
I've expected this to fail / be skipped there in general.
Also with regard to what py.path uses to determine if there is symlink support.

[nicoddemus]

The interesting part would be why / if symlinks always (seem) to work on Windows.
I've expected this to fail / be skipped there in general.

Oh sorry I missed that: Administrators and users with special permissions can create symlinks, normal users cannot. I suspect the user running in CI has admin privileges, that's why it works there.

Also with regard to what py.path uses to determine if there is symlink support.

It does the right thing to check for symlinks (just call os.path.islink).
https://github.com/pytest-dev/py/blob/962ad137fcfc52a218fc8acc3d87708eccf00bbc/py/_path/local.py#L373-L374

But yeah I need to set aside more time to investigate further and figure out what's going on.