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. ctags tests all the .py files use `#!/usr/bin/python` or `#!/usr/bin/env python` both of which will fail 4. as above for scripts 5. python templates use `#!/usr/bin/env python`
There may be more.
I'm surprised there isn't already an issue for this, but I can't find it, better googlers may.
https://github.com/geany/geany/issues/2615?
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?
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.
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.
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-g.... 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
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`?
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 I guess.
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.
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](https://github.com/geany/geany/blob/6ffaf515ef66d84ebece41abffda3bcdc390ab44...))
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)?
We use MSYS2 packages exclusively.
Ok, are there any build time python scripts we control? (except `gen-api-gtkdoc.py` run from [here](https://github.com/geany/geany/blob/6ffaf515ef66d84ebece41abffda3bcdc390ab44...))
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.
@elextr all of the parts mentioned in the OP are already resolved. Can we close this one?
Closed #2896 as completed.
github-comments@lists.geany.org