use python3 on debians too

[omarandlorraine]

in Debian 11 which is Bullseye, /usr/bin/python is a Python2
interpreter, which means that cppcheck-htmlreport fails to run here.
So I've changed the shebang to use python3

I'm really not sure what the package supplied by Debian themselves does; maybe they have to maintain a diff themselves or something!

[firewave]

Thanks for your contribution.

How does it fail with Python 2.7? We are currently still targeting Python 2.7 as the minimum version for most of our scripts (something that might change soon) so it should be working. The tests for cppcheck-htmlreport are currently passing on Python 2.7 - see

cppcheck/.github/workflows/scriptcheck.yml

Line 117 in 2c79481

- name: test htmlreport

for the test execution in the CI.

[omarandlorraine]

It's an import error actually; debian seems to not ship python-pygments in the standard repositories. Perhaps they stopped shipping it with Bullseye. But of course, they do ship python3-pygments.

EDIT: I just checked, Debian stopped shipping python-pygments with Buster, which is oldstable now. This means any new debian installs will not be able to run cppcheck-htmlreport without this change.

[firewave]

It's an import error actually; debian seems to not ship python-pygments in the standard repositories. Perhaps they stopped shipping it with Bullseye. But of course, they do ship python3-pygments.

Ugh. Well - you can still install it yourself via pip.

EDIT: I just checked, Debian stopped shipping python-pygments with Buster, which is oldstable now. This means any new debian installs will not be able to run cppcheck-htmlreport without this change.

Depending on the alternative set for python.
I came across this in our CI when I was switching over to Python provided by the platform (see #3776). I guess it's time to finally sunset Python 2.7 support.

IIRC there's a patch in the debian packaging which also does this change so if you are using the packaged version it will work.

[danmar]

well we could change the shebang I guess. for most users it would make better sense to use python3. For users that have old unix systems it's possible to run with explicit python, they can execute the script like: python htmlreport.

[firewave]

well we could change the shebang I guess. for most users it would make better sense to use python3. For users that have old unix systems it's possible to run with explicit python, they can execute the script like: python htmlreport.

As seen in the overview at #3596 (comment) Python 3.x is available across even quite old platforms. I really thinking we should get rid of Python 2.7. We are also inconsistent with python and python3 in our scripts and in our CI so a user and dev with both versions on their system will have an inconsistent experience as well. We did not recognize this since we use a fixed Python version in the CI. So similar to Qt we need to make sure it actually works on the actual platform.

[danmar]

I really thinking we should get rid of Python 2.7.

I don't have a very strong opinion right now actually. Python 2.x is probably not entirely dead yet. But even if a user is stuck with python 2.x for some reason, the cppcheck core functionality can still be used without python scripts.

[firewave]

I don't have a very strong opinion right now actually. Python 2.x is probably not entirely dead yet. But even if a user is stuck with python 2.x for some reason, the cppcheck core functionality can still be used without python scripts.

In that case he could override it with python2 <file>.py. We have tests that ensure we should be working with it. But the out-of-the-box behavior should be consistent i.e. use the python3 shebang across all files. In that case we would also have to do no additional changes if we remove Python 2.7 support.

[danmar]

In that case he could override it with python2 .py. We have tests that ensure we should be working with it. But the out-of-the-box behavior should be consistent i.e. use the python3 shebang across all files.

That is OK. Use python3 in all the shebangs. People that are stuck with python2 have to override..

[omarandlorraine]

That is OK. Use python3 in all the shebangs.

I've changed all the shebangs that had python to python3

[firewave]

I've changed all the shebangs that had python to python3

So let me adjust the CI first via #3776 first and then we should be able to put this in.

[firewave]

I think we should flag all those .py files as executable as well.

[danmar]

Merge branch 'danmar:main' into main

I would suggest that you use git rebase .. instead of git merge ...

[firewave]

I need to adjust the docker jobs as well - I already expected such. Will take a look later.

I would suggest that you use git rebase .. instead of git merge ...

It's definitely better but since we "squash merge" it doesn't matter at all.

FYI It makes a big difference in case you utilize reviews since a merge doesn't reset the review status where as a rebase does..

[firewave]

There's also a ticket about this - https://trac.cppcheck.net/ticket/10274.

[firewave]

Please rebase this after #4004 has been merged. I had to switch to Python 3.x in some of the jobs and made several adjustments which should make these changes work at last.

[firewave]

That PR has been merged. Please rebase.

[danmar]

@omarandlorraine I would like to add you in our AUTHORS file. What name would you like that I add?