Subject: Re: bug#70815: [PATCH] ; Enahnce python-tests.el to adapt different python interpreters

From: kobarity <[email-masked]>
Date: Sun, 12 May 2024 11:06:30 +0900

Lin Sun wrote:
> On Sat, May 11, 2024, 06:37 kobarity <[email-masked]> wrote:
> 
>  Eli Zaretskii wrote:
>  > 
>  > > From: Lin Sun <[email-masked]>
>  > > Date: Tue, 7 May 2024 06:53:05 +0000
>  > > 
>  > > The python-tests.el will fail on finding interpreter "python" for
>  > > there is no "python"  on CentOS8, Ubuntu 20.04,  only "python3" exists
>  > > after installation.
>  > 
>  > Thanks, I have some comments, and maybe kobarity will have as well.
> 
>  Hi Lin,
> 
>  Please correct the typo "Enahnce" in the title.
> 
>  I think the summary line of this commit should not begin with a
>  semicolon.  CONTRIBUTE says:
> 
>    If the summary line starts with a semicolon and a space "; ", the
>    commit message will be skipped and not added to the generated
>    ChangeLog file.  Use this for minor commits that do not need to be
>    mentioned in the ChangeLog file, such as changes in etc/NEWS, typo
>    fixes, etc.
> 
>  When revising the patch, please include the bug number.  CONTRIBUTE
>  says:
> 
>  - The commit message should contain "Bug#NNNNN" if it is related to
>    bug number NNNNN in the debbugs database.  This string is often
>    parenthesized, as in "(Bug#19003)".
> 
>  python-tests-get-shell-interpreter should have an docstring.  This can
>  be checked with checkdoc.  CONTRIBUTE says:
> 
>    Use 'checkdoc' to check for documentation errors before submitting a
>    patch.
> 
>  I recommend to use Flymake or Flycheck.  There are many violations in
>  python-tests.el, but I think it is better for new patches to follow
>  this rule.
> 
>  when-let* used in python-tests-get-shell-interpreter could be replaced
>  with when-let.
> 
> Hi Eli, kobarit,
> I'm trying change the code to follow your comments, will update later, thank you!

Hi Lin,
I noticed another issue.  If there is only python2 in the PATH and no
python or python3, some tests will fail.

20 unexpected results:
   FAILED  python-completion-at-point-1
   FAILED  python-completion-at-point-2
   FAILED  python-completion-at-point-native-1
   FAILED  python-completion-at-point-native-2
   FAILED  python-completion-at-point-native-with-eldoc-1
   FAILED  python-completion-at-point-native-with-ffap-1
   FAILED  python-completion-at-point-pdb-1
   FAILED  python-completion-at-point-while-running-1
   FAILED  python-eldoc--get-doc-at-point-1
   FAILED  python-eldoc--get-doc-at-point-while-running-1
   FAILED  python-ffap-module-path-1
   FAILED  python-ffap-module-path-while-running-1
   FAILED  python-shell-completion-at-point-1
   FAILED  python-shell-completion-at-point-jedi-completer
   FAILED  python-shell-completion-at-point-native-1
   FAILED  python-shell-prompt-detect-1
   FAILED  python-shell-prompt-detect-2
   FAILED  python-shell-prompt-set-calculated-regexps-6
   FAILED  python-test--shell-send-block
   FAILED  python-tests--run-python-selects-window

This is because `python-shell-interpreter' is not let-bound and is set
to "python3".

One way to resolve these would be to provide a thin wrapper like
`python-tests-shell-with-shell-buffer' and bind
`python-shell-interpreter' to (python-tests-get-shell-interpreter).

Current ERTs seem to support both Python 2/3, but it may become
necessary to write an ERT that supports only Python 3.  It would be
nice if the author of the ERT could specify an interpreter, but there
may be no need to prepare one now.