Detect when py is part of a symlink loop

[cactusdualcore]

Launcher will use itself as python if python is a symlink to py
If the installation of python found by py to be the best-suited installation is a symbolic link to py itself, it will call itself again, resulting in a unending loop.

To Reproduce
Steps to reproduce the behaviour:

1. Install py
2. Install venv-wrapper
3. Add py to $PATH so $ which py shows installation of py
4. Add venv-wrapper to $PATH
5. create a virtual environment with $ venv-wrapper new <name> -p "$(which py)"
6. activate virtual environment with $ venv-wrapper use <name>
7. execute $ python --version. No output will appear, because py calls itself repeatedly.

Expected behaviour
py should not call itself but either error or look for an actual python install.

Screenshots

$ python --version blocks until interrupted (e.g. by CTRL + C)

System Details (please complete the following information):

• OS: Linux Mint 20.3 x86_64
• Shell: zsh 5.8
• Launcher Version: 1.0.0

[brettcannon]

Why was the Python Launcher symlinked to python? What is venv-wrapper new <name> -p "$(which py)" expected to do?

[brettcannon]

If you're trying to get the path to the executable that the Launcher chooses, you could run py -c "import sys; print(sys.executable)".

[cactusdualcore]

Why was the Python Launcher symlinked to python?

Curiosity made me try whether py is a replacement to python and python3 to where it can be used as the referenced executable of a virtual python environment.

What is venv-wrapper new <name> -p "$(which py)" expected to do?

My assumption was for py to notice it is calling itself, warn the user this is unexpected and, if full interchangeability between py and python is wanted, to fall back to an actual python installation. I understand the latter might not be what py is trying to do, though I think a warning may be helpful if this arose by misunderstanding or similar.

[cactusdualcore]

If you're trying to get the path to the executable that the Launcher chooses, you could run py -c "import sys; print(sys.executable)".

This should work, though it might not be very useful. One big advantage of virtual python environments is to provide the same version of python for an application to be run with. If a new global install of python was considered more fit by the Launcher the edition of python could change.

[brettcannon]

I understand the latter might not be what py is trying to do, though I think a warning may be helpful if this arose by misunderstanding or similar.

How would the Python Launcher detect this?

One big advantage of virtual python environments is to provide the same version of python for an application to be run with.

Correct, but your example is calling something venv-wrapper which suggests you're trying to create a virtual environment. The line I gave you was for potential use as the argument to that -p option.

BTW, I consider this a feature request, so I am going to convert it to a Discussion.

[cactusdualcore]

A possible solution to the latter problem might be to compare the executable path and the found binary.

[cactusdualcore]

S_ISLNK(m)

symbolic link? (Not in POSIX.1-1996.)

It seems POSIX does not require an API to deal with symlinks and it seems as nix does not support checking whether a path is. Though Microsoft Windows, Linux and MacOS all have support for them.

[cactusdualcore]

The suggested check's results may change for different platforms. Especially on systems which allow hardlinks this can fail.