Configure test for python can fail, but with little apparent harm

I noticed that the configure test for PYTHON was failing on my machine. The configure test itself is

  AC_CHECK_PROG(PYTHON, python, python, [])

The issue is that on my machine the executable is now python3. Should we be calling AC_CHECK_PROGS instead and giving a list of possible names for the python executable? Or should we just require the user to set up a soft link if they need one?

As far as I can see this is used only one place in the build process, and it is a backup when Perl is not available.

libinterp/corefcn/ libinterp/corefcn/ libinterp/corefcn/ | libinterp/corefcn/$(octave_dirstamp)
	$(AM_V_GEN)rm -f $@-t && \
	if test -n "$(PERL)"; then \
	  $(SHELL) $(srcdir)/libinterp/corefcn/ --perl "$(PERL)" < $< > $@-t; \
	elif test -n "$(PYTHON)"; then \
	  $(SHELL) $(srcdir)/libinterp/corefcn/ --python "$(PYTHON)" < $< > $@-t; \
	else \
	  $(SHELL) $(srcdir)/libinterp/corefcn/ --sed "$(SED)" < $< > $@-t; \
	fi && \
	mv $@-t $@

Since 2005 (before Mercurial times) Octave is looking for Python. Is Python used somewhere in the Octave build process? I cannot remember :thinking:

On Unix the binary should be called python3. It is quite common to not have an unversioned python binary at all. If there is an unversioned python binary it should not be used for non-end-user stuff. Citation: PEP 394 – The “python” Command on Unix-Like Systems |

The situation on Windows is less clear (or was 2 years ago last I looked carefully at this!). There it seems that python.exe isnormal and python3 is not common (windows and the python3 binary · Issue #1010 · cbm755/octsympy · GitHub). My info may be out of date!

No. The only location is the one I documented in

Interesting. Octave has both perl.m and python.m which execute a perl or python script respectively. If I look at scripts/miscellaneous/python.m I see

    [status, output] = system (["python ", scriptfile, ...
                                sprintf(" %s", varargin{:})]);

which seems to hardcode the name of the python executable. That doesn’t seem right.

1 Like

Yeah that seems simplistic in the post-Python 2 reality… In Symbolic we have this file: octsympy/defaultpython.m at main · cbm755/octsympy · GitHub which basically returns “python3” on unix and “python” on Windows.

We also support PYTHON environment variable, which takes precedence over that default. This is done in octsympy/sympref.m at main · cbm755/octsympy · GitHub

Perhaps we should port some of that to core?

Can you file a bug report about this? I think this should be addressed and we need a place to keep track of it. The “configure” way to do this would be to expand to AC_CHECK_PROGS and then have a script such as with a variable substitution @PYTHON@ and then inform Autoconf that it should process to python.m. Honestly, that sounds like a lot of work. I think it might be better for python.m to use the detection logic from sympy that you pointed to.

For Octave’s build system itself, AC_CHECK_PROGS seems like the right choice.

Run-time sounds right to me, especially if you want to support the $PYTHON env var.

I’ll file one or two issues and post here

Excellent. I already have the fix for the build system ready to go.

Edit (7/9/22): I checked in a fix for the build issue here octave: 0c637fa9529a.

Biuld system: GNU Octave - Bugs: bug #62732, Is Python used in the build... [Savannah]

Python.m executable name: GNU Octave - Bugs: bug #62733, python.m feature needs more... [Savannah]

Edit (7/9/22): I (@rik) checked in a fix for python.m here octave: 6cfc7af8eacc.

And a downstream issue in octsympy to get this code ported over: port our python executable detection to upstream octave and use it here · Issue #1188 · cbm755/octsympy · GitHub

Maybe @alexvong1995 is interested in that?

This is pretty simple. Let me see if I can do this in a few minutes.

is pretty simple.

'tis but is also a nice entry point into core… :wink: