component/tesseract: do not hardcode python executable name for the case where only python3 exists.

component/ghostscript/buildout.cfg

@@ -25,7 +25,7 @@ configure-options =
   --without-libidn
   --without-x
   --with-drivers=FILES
-  --with-tessdata=$(python -c 'print("""${:tessdata-location}""".replace("//", "/"))')
+  --with-tessdata=$(${buildout:executable} -c 'print("""${:tessdata-location}""".replace("//", "/"))')
 environment =
   PATH=${pkgconfig:location}/bin:${xz-utils:location}/bin:%(PATH)s
   PKG_CONFIG_PATH=${:pkg_config_depends}

component/tesseract/buildout.cfg

@@ -28,7 +28,7 @@ pre-configure =
   autoreconf -ivf -I${pkgconfig:location}/share/aclocal -I${libtool:location}/share/aclocal -Wno-portability
 # XXX workaround path on slaprunner with a double slash
 # https://github.com/tesseract-ocr/tesseract/issues/3527
-configure-options = --prefix=$(python -c 'print("""@@LOCATION@@""".replace("//", "/"))')
+configure-options = --prefix=$(${buildout:executable} -c 'print("""@@LOCATION@@""".replace("//", "/"))')
 
 environment =
   PATH=${pkgconfig:location}/bin:${autoconf:location}/bin:${automake:location}/bin:${libtool:location}/bin:${m4:location}/bin:${patch:location}/bin:%(PATH)s

[Kazuhiko Shiozaki]

@jerome Thanks to @tomo this issue happened on the system where /usr/bin/python does not exist (but python3 exists). Is this change good, still keeping good 'shared' efficiency?

[Jérome Perrin]

I think it's OK, we should try to run SlapOS.SoftwareReleases.IntegrationTest-Master with this, it will tell if there's a problem like "shared part depending on something not shared from a software", in case ${buildout:executable} is somewhere in software (but I guess it's not)

As far as I remember, parts are anyway not shared between python2 softwares and python3 softwares, if this is what you were worried about.

[Jérome Perrin]

We could also use $PYTHON instead of ${buildout:executable} it's an environment variable set by component/defaults.cfg during build, but I'm not sure which one is best

[Jérome Perrin]

@tomo @xavier_thompson in theia this was not a problem because we have python in $PATH, but with slapos python3 softwares we no longer have python in $PATH ( in slapos python2 softwares we have it, only slapos python3 software do not have it, I realized recently that python3 does not installs bin/python c5cd4e06 (comment 168678) ). I start to believe it might be a good idea to not have a python in PATH with theia, because this was a scenario of "it works in theia"

[Thomas Gambier]

I start to believe it might be a good idea to not have a python in PATH with theia, because this was a scenario of "it works in theia"

Yes I agree. I would remove python from PATH in Theia.

[Xavier Thompson]

I agree as well, and we can probably easily remove (rename) the python that is generated in the software's buildout:bin-directory, but so far we've also kept the host's /usr/bin in PATH and there's often a python there as well.

[Jérome Perrin]

Yes, we cannot remove /usr/bin because we need few "core" programs for compilation. One thing I would like to try (first in software/slapos-sr-testing and in theia) is to put a "broken" python in $PATH, a program that would just print an error message explaining that the user should use python3 or python2 and exit with error code.

[Jérome Perrin]

I tried this idea of putting a broken python in $PATH for slapos-sr-testing in !1278 (merged)

[Jérome Perrin]

With !1282 (comment 171958) theia does not have "python" either