Hardcoded "python3" value for executable breaks Windows installs

[juanjosegarciaripoll]

Thank you for taking the time to report an issue and improve Flycheck. This template is for actual bugs you observed. If you have trouble setting up Flycheck, or if you have a question, please use the relevant issue template instead.

Checklist

• I have checked existing issues for potential duplicates before creating this one.
• I have read the [Troubleshooting guide][].

Bug description

Flycheck's Python checkers all have "python3" hardcoded as the path for the Python interpreter. This means that on Windows with an installation such as Miniforge or Anaconda or Mambaforge non of the checkers works by default, even if available. Instead, Flycheck finds a stub that ships with Windows and tells the user to install a Python distribution.

Steps to reproduce

Steps to reproduce the behavior:

1. Install Miniforge on Windows
2. Launch Emacs
3. Launch flycheck-mode on an open Python file
4. Flycheck fails because it cannot find python3, as python is the name of the executable, or it finds a fake python3 file that Microsoft ships with all operating systems.

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

Flycheck should honor other variables that determine the nameof the Python executable in a given setup, as single point of configuration.

System configuration

Syntax checkers for buffer mps.py in python-ts-mode:

First checker to run:

  python-pycompile
    - may enable:    yes
    - executable:    Found at c:/Users/juanj/AppData/Local/Microsoft/WindowsApps/python3.exe
    - next checkers: python-mypy

Checkers that are compatible with this mode, but will not run until properly configured:

  python-flake8 (automatically disabled) reset
    - may enable:         yes
    - executable:         Found at c:/Users/juanj/miniforge3/envs/quantum/python.exe
    - configuration file: Not found
    - `flake8' module:    Found at "c:\\Users\\juanj\\miniforge3\\envs\\quantum\\Lib\\site-packages\\flake8\\__init__.py"
    - next checkers:      python-pylint, python-mypy

  python-ruff (automatically disabled) reset
    - may enable:         no
    - executable:         Not found
    - configuration file: Found at "c:/Users/juanj/src/seemps2/pyproject.toml"
    - next checkers:      python-mypy

  python-pylint (automatically disabled) reset
    - may enable:         no
    - executable:         Found at c:/Users/juanj/AppData/Local/Microsoft/WindowsApps/python3.exe
    - configuration file: Found at "c:/Users/juanj/src/seemps2/pyproject.toml"
    - `pylint' module:    Missing; sys.path is nil
    - next checkers:      python-mypy

  python-pyright (automatically disabled) reset
    - may enable: no
    - executable: Not found

  python-mypy (automatically disabled) reset
    - may enable:         yes
    - may run:            t
    - executable:         Found at c:/Users/juanj/miniforge3/envs/quantum/Scripts/mypy.exe
    - configuration file: Found at "c:/Users/juanj/src/seemps2/pyproject.toml"

Flycheck Mode is enabled.  Use C-u C-c ! x to enable disabled
checkers.

--------------------

Flycheck version: 20240229.628
Emacs version:    29.2
System:           x86_64-w64-mingw32
Window system:    w32

Emacs configuration:

• Plain Emacs / Custom configuration
• Spacemacs
• Doom Emacs
• Other shared configuration

[bbatsov]

Can you seen https://www.flycheck.org/en/latest/user/syntax-checkers.html#change-syntax-checker-executables ?

[juanjosegarciaripoll]

That is a horrible solution, buffer by buffer and manual. Instead, one may alias all of Flycheck's Python checkers to python-shell-executable, but that defeats the purpose: the user has to reconfigure Flycheck to use Emacs' standard variable to replace a hardcoded one. Furthermore, due to python3.exe being a stub file, not a Python interpreter in Windows, Flycheck's diagnostics of the problem to the user are difficult to interpret.

[cpitclaudel]

Aliasing is the right solution, but it would indeed be nice if we did it by default. The problem here is that (IIRC) we can't define an alias between python-mode variables and ours without loading python.el, but we don't want to load python.el for everyone just to define an alias.

[bbatsov]

See also #1055