chore: drop Python 3.9, add timeouts, fix test passing logic

[ariostas]

This PR drops testing on Python 3.9, adds timeout to tests to make sure they don't get stuck, adds retries to dask-awkward tests, and fixes the logic to determine if all tests passed.

[ikrommyd]

Thanks @ariostas! I was gonna do that today since we dropped py3.9 in coffea main yesterday

[ariostas]

@pfackeldey since you have more experience with uv, what's the right way to install awkward-cpp from the main branch into the uv environment?

[ikrommyd]

I am aware of this syntax

uv pip install git+https://github.com/scikit-hep/awkward.git#subdirectory=awkward-cpp

but this still runs into the problem

      CMake Error at CMakeLists.txt:29 (message):
        awkward-cpp relies upon generated and copied artefacts such as the
        header-only libraries and generated kernel headers.  These could not be
        found, which indicates that



            nox -s prepare



        was skipped or failed.  Please check
        https://github.com/scikit-hep/awkward#installation-for-developers to learn
        more about this process.



      *** CMake configuration failed

      hint: This usually indicates a problem with the package or the build environment.

Probably just cloning in ci, run nox -s prepare for awkward and install with uv pip install -v ./awkward-cpp as if you were installing for local development is just best. You can also just install awkward too in the same step since you would be cloning anyways.

[ikrommyd]

@henryiii is there a way to get awkward-cpp from main without cloning? Should there be a way if that's not the case? Can this nox -s prepare requirement be ditched?

[henryiii]

I think we could trigger that via cmake instead of via nox, then it would be possible.

[ariostas]

Probably just cloning in ci, run nox -s prepare for awkward and install with uv pip install -v ./awkward-cpp as if you were installing for local development is just best. You can also just install awkward too in the same step since you would be cloning anyways.

This is what I tried doing here, but I'm not sure why it's not working.

integration-tests/.github/workflows/test_awkward_dask-awkward_uproot_coffea_vector.yml

Lines 103 to 107 in 0879e2c

	- name: Build awkward-cpp and awkward
	run: |
	cd repo-awkward
	pipx run nox -s prepare -- --headers --signatures --tests
	uv pip install --project .. -vv '.[test]' ./awkward-cpp -r requirements-test-full.txt

[ikrommyd]

Probably just cloning in ci, run nox -s prepare for awkward and install with uv pip install -v ./awkward-cpp as if you were installing for local development is just best. You can also just install awkward too in the same step since you would be cloning anyways.

This is what I tried doing here, but I'm not sure why it's not working.

integration-tests/.github/workflows/test_awkward_dask-awkward_uproot_coffea_vector.yml

Lines 103 to 107 in 0879e2c

	- name: Build awkward-cpp and awkward
	run: |
	cd repo-awkward
	pipx run nox -s prepare -- --headers --signatures --tests
	uv pip install --project .. -vv '.[test]' ./awkward-cpp -r requirements-test-full.txt

ci right now shows failures in the "Save results to file" step, not installation. You can also use uvx instead of pipx btw. Also, If I remember correctly, awkward does not provide any extras so [test] is not doing anything.

[ikrommyd]

Uhmmm @ariostas in the last ci run, the windows py3.13 tests failed but I do not see a single actual test failure in the logs

[ikrommyd]

Looks good now!

[pfackeldey]

Awesome! thanks for doing this!
(I agree about keeping dask-awkward optional, it's CI is sometimes pretty flaky for unknown reasons.)
Out of curiosity will dask-awkward still show up in the summary table but with a failure (even though the full tests pass, because it's optional)?

[ariostas]

Out of curiosity will dask-awkward still show up in the summary table but with a failure (even though the full tests pass, because it's optional)?

@pfackeldey Yeah, that's right. You can see that it happened in the latest run: https://github.com/scikit-hep/integration-tests/actions/runs/19680002339 . So before making a release maybe it's still worth checking the summary of the nightly run and making sure that the dask-awkward row is not all Xs. I guess one simple alternative would be to check that there's no more than, say, 3 Xs in the table, and fail the job otherwise.

Btw, Iason and I were wondering if you know which of the tests are the flaky ones. We've seen one very flaky and one less flaky one. One option could be to exclude only those and make the rest required (maybe even upstream?).