Python 3.13 Support, 3.8 EOL

[ax3l]

Add support for Python 3.13.
Remove 3.8 because it is EOL as of Oct 2024.

Bump to pybind11 2.13.0+, which add Python 3.13 support in CI.

[roelof-groenewald]

Does this comment mean the CI uses Python 3.8?

[ax3l]

Yes, a few CI runners still use Python 3.8 and for me that is ok for now.
We can bump this once we update CI runners for 3.9+.

[roelof-groenewald]

Looks good to me!

[EZoni]

I did a quick grep of python-version in our workflows and this is what I see:

$ git grep "python-version" .github/
.github/workflows/cuda.yml:30:        python-version: '3.x'
.github/workflows/windows.yml:24:        python-version: '3.x'
.github/workflows/windows.yml:75:        python-version: '3.8'

I think 3.x gets the "latest minor release", if I understand correctly what is explained here: https://docs.github.com/en/actions/use-cases-and-examples/building-and-testing/building-and-testing-python#using-a-specific-python-version.

So maybe the only job that uses Python 3.8 is "Clang C++17 w/ OMP w/o MPI" in the "Windows" workflow:

WarpX/.github/workflows/windows.yml

Lines 67 to 119 in d0690e2

	build_win_clang:
	name: Clang C++17 w/ OMP w/o MPI
	runs-on: windows-2019
	if: github.event.pull_request.draft == false
	steps:
	- uses: actions/checkout@v4
	- uses: actions/setup-python@v5
	with:
	python-version: '3.8'
	- uses: seanmiddleditch/gha-setup-ninja@master
	- name: CCache Cache
	uses: actions/cache@v4
	# - once stored under a key, they become immutable (even if local cache path content changes)
	# - for a refresh the key has to change, e.g., hash of a tracked file in the key
	with:
	path: |
	~/.ccache
	~/.cache/ccache
	key: ccache-windows-winclang-${{ hashFiles('.github/workflows/windows.yml') }}-${{ hashFiles('cmake/dependencies/AMReX.cmake') }}
	restore-keys: |
	ccache-windows-winclang-${{ hashFiles('.github/workflows/windows.yml') }}-
	ccache-windows-winclang-
	- name: Build & Install
	shell: cmd
	run: |
	call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\vc\Auxiliary\build\vcvarsall.bat" x64
	cmake -S . -B build ^
	-G "Ninja" ^
	-DCMAKE_C_COMPILER=clang-cl ^
	-DCMAKE_CXX_COMPILER=clang-cl ^
	-DCMAKE_BUILD_TYPE=Release ^
	-DCMAKE_VERBOSE_MAKEFILE=ON ^
	-DWarpX_COMPUTE=OMP ^
	-DWarpX_EB=OFF ^
	-DWarpX_PYTHON=ON ^
	-DWarpX_MPI=OFF ^
	-DWarpX_OPENPMD=ON
	if errorlevel 1 exit 1
	cmake --build build --config Release --parallel 4
	if errorlevel 1 exit 1
	cmake --build build --config Release --target install
	if errorlevel 1 exit 1
	python3 -m pip install --upgrade pip
	if errorlevel 1 exit 1
	python3 -m pip install --upgrade build packaging setuptools wheel
	if errorlevel 1 exit 1
	python3 -m pip install --upgrade -r requirements.txt
	if errorlevel 1 exit 1
	cmake --build build --config Release --target pip_install
	if errorlevel 1 exit 1

Do we want to try to upgrade this Python version directly in this PR, if Python 3.8 is EOL as of October 2024?

[ax3l]

There are a few more that use Ubuntu 20.04 without setup-python at the moment.

The way to update these would be to bump to 22.04 or, where we intentionally test an old compiler to ensure we can still use it (e.g., old NVCC that we specify as our minimum requirement), use setup-python. I can push this here so we have it all together.

[ax3l]

Ah yes, and Azure runs on Ubuntu 20.04 and checksums are too strict: #5203
I am not aware of a setup-python trick for Azure pipelines.