Hardcoded "python3" in tests/test_ansi2html.py

[johanneskastl]

tests/test_ansi2html.py contains a hardcoded python3 executable name, which makes this test fail if there is no python3 available (but python3.11 or similar).

The patch is easy, I'll open a PR once Github fixes the outage that prevents forking this repository...

[hartwork]

Hi @johanneskastl please allow me to do a quick braindump:

• note to self, this is about a subprocess call not a shebang line
• we could use sys.executable rather than 'python3', technically.
• I believe it's fine to expect availability of command python3. Please help me understand why your environment is missing that command and/or file and why that is considered intact. Is this with a virtualenv or without? Which distro? Are you dropping things from $PATH? There is probably something to fix outside of ans2html also or primarily, but let's see.

[johanneskastl]

Sorry for the duplicate issues, somehow Github threw lots of 500 errors on me and did not show that it already created the issue...

I have a patch ready that solves this for us, as soon as I am allowed to fork the repo I'll open a PR.

The environment is for building a package for openSUSE, where there is only python3.11 but no python3 executable.
Or it should use the same executable it was called with, in case there is more than one python version available.

[hartwork]

Sorry for the duplicate issues, somehow Github threw lots of 500 errors on me and did not show that it already created the issue...

@johanneskastl no worries 👍

I have a patch ready that solves this for us, as soon as I am allowed to fork the repo I'll open a PR.

Thanks!

it should use the same executable it was called with, in case there is more than one python version available.

That's a fair point 👍

The environment is for building a package for openSUSE, where there is only python3.11 but no python3 executable.

Why is that considered an intact environment? Doesn't this break a lot of things? #! /usr/bin/env python3 is a standard Python 3 shebang for instance. Please help me understand.

[hartwork]

PS: @johanneskastl for backup of my argument, I would like to share this reference:

We expect Unix-like software distributions [..] to install the python2 command into the default path whenever a version of the Python 2 interpreter is installed, and the same for python3 and the Python 3 interpreter.

(from https://peps.python.org/pep-0394/#for-python-runtime-distributors)

[johanneskastl]

The environment is for building a package for openSUSE, where there is only python3.11 but no python3 executable.

Why is that considered an intact environment? Doesn't this break a lot of things? #! /usr/bin/env python3 is a standard Python 3 shebang for instance. Please help me understand.

In this case the regular python3 is provided by a different python version (3.6) that cannot be changed. But the package I am trying to build is for a newer python stack that is to be installed in parallel. And which is not the same version.

Hence using python3 would run python3.6, while the package itself is for python3.11...

And during build only python3.11 is available, which is not providing the python3 executable.

Does this explain things a little?

[hartwork]

@johanneskastl this sounds contradictory:

• Either there is a python3 command available and it's 3.6 then the original statement "there is no python3 available" was not correct and it's about a mix-up and your environment is complete with regard to PEP 394 OR
• there is no python3 command available then it should be made available to be a complete environment and ansi2html would not even need patching in your context because python3 is there and it's the same 3.11.

Please help me clean up the picture. Thanks!

[johanneskastl]

Sure.

During the RPM build only the required dependencies are present, which means python3.11 but no python3.6. Hence no python3 executable.

This is done because python3.11 MUST NOT provide this executable, so it can be installed in parallel to 3.6 later on an actual server.

On the server there is a python3 present, but it is 3.6 and not 3.11 which the package is built for. Hence this comment:

it should use the same executable it was called with, in case there is more than one python version available.

[hartwork]

@johanneskastl okay, thanks for elaborating 👍

[johanneskastl]

@johanneskastl okay, thanks for elaborating +1

Sure, sorry for not being concise in the first place.