Lately I have been working on a CentOS 8 machine, and it has "python2" and "python3", but no "python". Many packages install scripts with a shebang like: #!/usr/bin/env python and those do not work on this OS. Seems like rather a large missing dependency which goes by without triggering a fatal error. In bioinformatics pipelines it is common for one package to invoke a script from another. So while the package which supplied a particular script might have avoided this issue by only invoking it with: python3 path/script that does not prevent another package from doing one of these: A path/script B python path/script In terms of analysis, it is trivial to find all python scripts installed by a package and examine the shebang line (if present) to see if this is an issue. I am adding a "reshebang" function to my python_devirtualizer specifically to handle the issue for scripts which are invoked directly. It is, however, not at all trivial to analyze all a package's code to see which scripts are called by other scripts, and how they are called. Moreover, they might be called from perl, or C, or some other language. So dealing with "B" above is not trivial. So, my question is, should the use of "python" (as opposed to "python2" or "python3") in a shebang be considered an installation error on a system for which "python" does not exist? I would argue yes, because we already know that python3 was not fully backwards compatible with python2, so we have reason to suspect that python4 (whenever that appears) might also not be fully backwards compatible with python3. By being picky about the python version now, that should prevent a lot of problems later. Regards, David Mathog