python vs python3 shebang

Hello folks,

We have a mixture of python(2) vs python3 shebang usage in llvm codebase.

As python2 upstream support has ended, what’s the LLVM policy here? Shall we change the shebang to python3 for all scripts?

  • For llvm-developer-only python scripts (e.g. clang-tidy/add_new_check.py), it is safe to do this change, as LLVM development requires python >= 3.6
  • For python scripts being interacted with people’s workflow (e.g. clang-format-diff.py), it seems unclear to me, changing the shebang would break people’s workflow on python2 machines.

I have some patches (https://reviews.llvm.org/D101038, https://reviews.llvm.org/D101037). What do people think?

Thanks,
Haojian

As far as I remember, it’s trickier on Windows where there is a special hack for shebang to python specifically.

-Valeriy

This is coming up now in part because debian testing has removed /usr/bin/python, so #!/usr/bin/env python no longer works on such systems.

Relevant is https://www.python.org/dev/peps/pep-0394/, which I think basically says if we want to maintain scripts that work both on py2-only systems and py3-only systems there’s no real answer other than adding an installer that rewrites the shebang lines :frowning:

Agree that for tools used by LLVM devs #!/usr/bin/env python3 seems like a good change.
For user-facing tools it seems we have 3 “easy” options for the checked-in scripts:
A) use python2 and break on some new systems
B) use python3 and break on some old systems
C) use python and break on systems that don’t provide the alias
None of these seem nice.

As far as I remember, it’s trickier on Windows where there is a special hack for shebang to python specifically.

Any idea where this hack lives? Would be nice to check if it’s updated.

Any idea where this hack lives? Would be nice to check if it’s updated.

It’s not a hack in the LLVM codebase (that would be easier). What I remember from previous discussions about Python, is that it finds #!/usr/bin/env python and uses installed Python2 interpreter or something, but doesn’t have the same trick for python3 or smth.But again, I can be very wrong here.

-Valeriy

Sounds like the python windows launcher, which the original spec says does have py3 support
https://www.python.org/dev/peps/pep-0397/#python-script-launching

(But I don’t have direct experience)

Yes, py.exe sniffs shebangs and dispatches accordingly.

In the context of build systems, shebangs should never come into play because the build system should invoke the script with the Python interpreter detected at configure time. E.g. “$PYTHON3 my_script”. (I don’t know if this is the case with LLVM.)

For what’s under source control, it is best to default to “#!/usr/bin/env python2.7” and “#!/usr/bin/env python3[.x]” (.x to target a specific release, but that’s generally not necessary/wanted, as it precludes using newer versions).

It is true some environments don’t have the python2[.x] or python3[.x] aliases or the “python” alias violates PEP desired behavior (I think Homebrew falls in this boat). You can leave it up to downstream packagers to deal with this mess. But this being an established project with a real build system, you’ll probably want to teach the installer to rewrite shebangs using an optional value provided to the configuration step.

This is coming up now in part because debian testing has removed
/usr/bin/python, so #!/usr/bin/env python no longer works on such systems.

The link can actually be easily restored by installing the package
"python-is-python2" [1]. I currently have that package installed on all
my Debian machines.

Adrian