Python usage in build

[elextr]

I'm surprised there isn't already an issue for this, but I can't find it, better googlers may.

The python checks and commands used in the build need updating to python3. The python command does not exist on many systems now.

1. configure.ac checks for python so the docs have to be disabled here, even though I have python3 and a rst2html with #!/usr/bin/python3 shebang.
2. geany_gtkdoc_header.m4 explicitly checks for Python 2.7 if I read it right.
3. gen_api_gtkdoc.py uses #!/usr/binenv python

See also #2615, these kept here with milestone of next release so release builds will work (unless releasers and packagers have python2 and 3).

[eht16]

I'm surprised there isn't already an issue for this, but I can't find it, better googlers may.

#2615?

[elextr]

Thanks @eht16, dunno why it didn't show in my search, but anyway that doesn't have the configure.ac so I left it and the other two build scripts and put them here so we have the milestone of next release.

So first question, what should configure.ac test for, python3? And is the windows py still relevant?

geany_gtk_doc_header.m4 is entirely @b4n ping

gen_api_gtkdoc.py has had lots of contributors, so anybody know if it will run on python3?

[elextr]

I guess its possible for configure.ac to test for python2 and we only have to change the shebang and don't have to check the scripts work on Python 3 for 1.38.

But then still need Python 3 for docutils, so my preference would be to go all python3 for 1.38.

[djhenderson]

On Wed, 15 Sept 2021 at 18:48, elextr ***@***.***> wrote: | Thanks @eht16 <https://github.com/eht16>, dunno why it didn't show in my | search, but anyway that doesn't have the configure.ac so I left it and | the other two build scripts and put them here so we have the milestone of | next release. | | So first question, what should configure.ac test for, python3? And is the | windows py still relevant? It should test for "python" first, and then execute python -V to get the version and test for "version > 3". If either fails, it should test for "python3" and accept any version. If that fails it should report that it requires a "python version > 3". Python2 is no longer supported except (for maybe source only) releases for security fixes. Unless we make a pure windows build using the Microsoft tool chain, we should not look for "py". | geany_gtk_doc_header.m4 is entirely @b4n <https://github.com/b4n> ping Does this mean it is OK? I.e. in geany's control. | gen_api_gtkdoc.py has had lots of contributors, so anybody know if it will run on python3 I found a copy of gen_api_gtkdoc.py at https://nest.parrot.sh/packages/debian/geany/-/blob/master/scripts/gen-api-gtkdoc.py. It uses "#!/usr/bin/env python" and I "saw" no python2 only code. I did not look to see if they were patching it as their commits had over 1000 files. Doug

…

-- Doug Henderson, Calgary, Alberta, Canada - from gmail.com Edit: clean up emailed comment (a bit).

[elextr]

It should test for "python" first, and then execute python -V to get the version and test for "version > 3". If either fails, it should test for "python3" and accept any version. If that fails it should report that it requires a "python version > 3".

The Python PEP requires the versioned python3 command to be installed even if python is also installed, so I don't see the point of such complications, especially trying to do it in autoconf m4. If we require python3 say so and test for it.

geany_gtk_doc_header.m4 is entirely @b4n https://github.com/b4n ping

Does this mean it is OK? I.e. in geany's control.

Its in this Geany repo, so yeah.

Ditto gen_api_gtkdoc.py, what debian does to it is their concern.

Unless we make a pure windows build using the Microsoft tool chain, we should not look for "py".

@eht16 which Python does the new windows build use, one in msys2 that is called python3 or a Windows install that still needs py? Can we drop the py?

[elextr]

Debian patch for geany_gtk_doc_header.m4:

From: Chow Loong Jin <hyperair@debian.org>
Date: Sun, 4 Apr 2021 02:08:19 +0800
Subject: Use python3 for generating gtkdoc header

---
 m4/geany-gtkdoc-header.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/geany-gtkdoc-header.m4 b/m4/geany-gtkdoc-header.m4
index 2b6d87f..b8828f1 100644
--- a/m4/geany-gtkdoc-header.m4
+++ b/m4/geany-gtkdoc-header.m4
@@ -21,7 +21,7 @@ AC_DEFUN([GEANY_CHECK_GTKDOC_HEADER],
 	      [test "x$geany_enable_gtkdoc_header" != "xno"],
 	[
 		dnl python
-		AM_PATH_PYTHON([2.7], [have_python=yes], [have_python=no])
+		AM_PATH_PYTHON([3], [have_python=yes], [have_python=no])
 		dnl lxml module
 		AS_IF([test "x$have_python" = xyes],
 		      [have_python_and_lxml=yes

So I guess Python3 must work there.

[eht16]

So first question, what should configure.ac test for, python3? And is the windows py still relevant?

I just tested the Python 3.9 installer and it still installs the py launcher by default but not the real binaries.So, nothing has changed and the py launcher still seems like a good default for the filetype configuration.

(Btw, this installer is executed via Wine.)

gen_api_gtkdoc.py has had lots of contributors, so anybody know if it will run on python3?

Of course it does.
My Linux machine has no Python2 installed and I still can build Geany :).
I'm not completely sure but I think the MSYS2 installation on my Windows machine also has no Python2 installed.

It should test for "python" first, and then execute python -V to get the version and test for "version > 3". If either fails, it should test for "python3" and accept any version. If that fails it should report that it requires a "python version > 3".

The Python PEP requires the versioned python3 command to be installed even if python is also installed, so I don't see the point of such complications, especially trying to do it in autoconf m4. If we require python3 say so and test for it.

Let's check for and use python3 generally. As Lex said, if Python3 is available, it is available as python3 at the very least.

Unless we make a pure windows build using the Microsoft tool chain, we should not look for "py".

Don't mix different things here.
The whole thing about the py check is for the default value in `data/filedefs/filetypes.python.in. This is a configuration file.

@eht16 which Python does the new windows build use, one in msys2 that is called python3 or a Windows install that still needs py? Can we drop the py?

The py launcher is not used when building Geany. The MSYS2 Windows builds (natively on a Windows machine as well as the cross builds) use normal python(|2|3) commands, in all their variants but in the same way as on non-Windows.
To be clear, the official Python installer nor the py launcher is necessary for building Geany. We use MSYS2 packages exclusively.

[elextr]

I just tested the Python 3.9 installer and it still installs the py launcher by default but not the real binaries.So, nothing has changed and the py launcher still seems like a good default for the filetype configuration.

Yes for sure, I was only talking about for the build.

The whole thing about the py check is for the default value in `data/filedefs/filetypes.python.in. This is a configuration file.

Ahhh, ok, so yes these days it definitely needs to be python3 or py so Geany users code will work out of the box.

We use MSYS2 packages exclusively.

Ok, are there any build time python scripts we control? (except gen-api-gtkdoc.py run from here)

If any I guess they use the shebang, so we just need to change that, and apply the Debian patch for the above.

And do we check for a Python for the build (eg for rst2html)?

[eht16]

We use MSYS2 packages exclusively.

Ok, are there any build time python scripts we control? (except gen-api-gtkdoc.py run from here)

If any I guess they use the shebang, so we just need to change that, and apply the Debian patch for the above.

I didn't check the shebangs but I'm pretty much sure my MSYS2 environment has no Python2 installed (though it might be a python command is available targeting to Python3). I'll check this next time when booting the machine.

And do we check for a Python for the build (eg for rst2html)?

Not explicitly, I think.

Apart from that, I think the 1.38 milestone is a bit optimistic. I'm sure we can and should solve all related issues for 1.38. After all, using only Python3 for builds is nice to have but not release critical.

[eht16]

@elextr all of the parts mentioned in the OP are already resolved. Can we close this one?