Fix gdal

[maurerle]

User description

This should fix the pipeline failing because of some GDAL issues

---

PR Type

Bug fix, Enhancement, Configuration changes

---

Description

• Stabilize GDAL pip installs in CI

• Disable GDAL build isolation; pin NumPy

• Run newgdal tests in CI

• Raise minimum Python version to 3.10

---

Diagram Walkthrough

flowchart LR
  ciWorkflows["GitHub Actions workflows"] 
  gdalInstall["GDAL Python bindings install"] 
  buildIsolation["Disable pip build isolation"] 
  numpyPin["Preinstall NumPy/setuptools/wheel"] 
  testsCfg["Pytest configuration"] 
  newgdalTests["Enable newgdal tests"] 
  pythonReq["Python version support"] 
  py310["Require Python >= 3.10"] 

  ciWorkflows -- "adds dedicated GDAL step" --> gdalInstall
  gdalInstall -- "uses" --> numpyPin
  gdalInstall -- "uses" --> buildIsolation
  testsCfg -- "removes marker exclusion" --> newgdalTests
  pythonReq -- "bumps minimum" --> py310

Loading

File Walkthrough

	Relevant files
Bug fix	gh-pages.yml Make GDAL install reproducible for docs build                        .github/workflows/gh-pages.yml Add dedicated step to install GDAL bindings Preinstall setuptools, wheel, and numpy Install GDAL with --no-build-isolation +4/-1
Miscellaneous	publish.yml Standardize GDAL version install quoting                                  .github/workflows/publish.yml Use ${GDAL_VERSION} expansion in pip command +1/-1
Configuration changes	python-test.yml Stabilize GDAL install and adjust CI matrix                            .github/workflows/python-test.yml Add dedicated step to install GDAL bindings Preinstall setuptools, wheel, and numpy Install GDAL with --no-build-isolation Reduce tested Python versions in matrix +5/-2      pyproject.toml Bump minimum Python and enable `newgdal` tests                      pyproject.toml Set requires-python to >=3.10 Remove Python 3.9 classifier entry Remove default not newgdal pytest marker filter +1/-4

---

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 5c3773d)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review CI Mismatch The publish workflow installs gdal without the same stabilization steps used elsewhere (no preinstall/upgrade of numpy/setuptools/wheel and no --no-build-isolation). If the original pipeline failure was caused by GDAL building in isolation or pulling an incompatible NumPy, this workflow can still fail even after the other workflows are fixed. - name: Install apt dependencies run: | sudo apt-get update sudo apt-get -qq install exiftool libgdal-dev libzbar0t64 GDAL_VERSION=$(gdal-config --version) pip install "gdal==${GDAL_VERSION}" - name: Install package and test dependencies run: pip install -e ".[test]" CI Break Risk Adding Python 3.14 to the test matrix can break CI if actions/setup-python does not provide that version on ubuntu-latest (or if key dependencies like gdal wheels/SDist build dependencies are not available for it yet). This would cause the entire matrix job to fail for that version even if the code is fine. test: needs: [lint] runs-on: ubuntu-latest strategy: fail-fast: false matrix: python-version: ["3.10", "3.12", "3.14"] steps: Test Fail Risk Removing the default -m "not newgdal" selection makes newgdal tests run in every pytest invocation. This can cause test failures in environments that don’t have a sufficiently new GDAL stack (or don’t have GDAL installed), impacting local contributors and downstream CI that runs pytest without reproducing the GDAL install steps from GitHub Actions. markers = [ "newgdal: tests that require newer GDAL stack behavior", ] addopts = [ "--cov=micasense", "--cov-report=xml", "--cov-report=term-missing", ]

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 5c3773d

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use only released Python versions Replace 3.14 with a released CPython version; actions/setup-python will fail because 3.14 is not available. Align the matrix with supported versions (and your classifiers) to keep CI green. .github/workflows/python-test.yml [26] -python-version: ["3.10", "3.12", "3.14"] +python-version: ["3.10", "3.11", "3.12", "3.13"] Suggestion importance[1-10]: 8 __ Why: Using python-version: ["3.10", "3.12", "3.14"] is likely to break CI because actions/setup-python commonly doesn’t provide unreleased versions under a plain 3.14 spec. Aligning the matrix with currently supported/released versions (and the project’s pyproject.toml classifiers) is a high-impact fix for pipeline reliability.	Medium
	Stabilize GDAL install during publish Make the GDAL install consistent with the other workflows by pre-installing build prerequisites and disabling build isolation. This avoids common GDAL build failures (missing/incorrect numpy during build) in the publish pipeline. .github/workflows/publish.yml [33-34] GDAL_VERSION=$(gdal-config --version) -pip install "gdal==${GDAL_VERSION}" +python -m pip install -U setuptools wheel numpy +python -m pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}.*" Suggestion importance[1-10]: 6 __ Why: Pre-installing setuptools, wheel, and numpy and using --no-build-isolation is a practical way to reduce GDAL build/install failures in CI, and it also makes the publish workflow consistent with the other workflows in this PR. The change is not strictly required if binary wheels are always available, but it improves robustness.	Low
	Relax GDAL version exact match Use a prefix match for the GDAL Python package version to tolerate patch/build suffixes (common in the gdal PyPI releases). This prevents hard failures when gdal-config --version doesn't exactly equal the PyPI version string. .github/workflows/gh-pages.yml [36-38] GDAL_VERSION=$(gdal-config --version) -pip install -U setuptools wheel numpy -pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" +python -m pip install -U setuptools wheel numpy +python -m pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}.*" Suggestion importance[1-10]: 6 __ Why: Switching from an exact gdal==${GDAL_VERSION} pin to a wildcard match like gdal==${GDAL_VERSION}.* can prevent failures when the PyPI gdal version includes an extra patch/build component not reflected by gdal-config --version. This is a reasonable CI-hardening change with moderate impact.	Low

---

Previous suggestions

Suggestions up to commit efd0917

Category	Suggestion	Impact
Possible issue	Use supported Python versions The 3.14 interpreter is not generally available on GitHub-hosted runners yet, so this matrix will likely fail at actions/setup-python. Replace it with currently supported versions (e.g., restore 3.11/3.13) to keep CI runnable. .github/workflows/python-test.yml [25-26] matrix: - python-version: ["3.10", "3.12", "3.14"] + python-version: ["3.10", "3.11", "3.12", "3.13"] Suggestion importance[1-10]: 8 __ Why: Using 3.14 in the matrix.python-version is very likely to break CI because actions/setup-python typically only supports released CPython versions on GitHub-hosted runners. Restoring currently supported versions (e.g., 3.11/3.13) materially improves workflow reliability.	Medium
	Make GDAL install reliable Building gdal from source can fail without preinstalled build prerequisites (notably numpy) and may require disabling build isolation to use the system GDAL. Mirror the installation approach used in the other workflows to reduce publish/test flakiness. .github/workflows/publish.yml [33-34] GDAL_VERSION=$(gdal-config --version) -pip install "gdal==${GDAL_VERSION}" +pip install -U setuptools wheel numpy +pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" Suggestion importance[1-10]: 7 __ Why: Installing gdal via pip can fail or become flaky without ensuring build prerequisites like numpy and without --no-build-isolation when targeting the system GDAL. Aligning publish.yml with the more robust install pattern used elsewhere reduces CI/package test failures.	Medium
General	Upgrade build tools before GDAL Installing older preinstalled setuptools/wheel can still cause GDAL build failures on some runners. Upgrade these build tools consistently (as done in the test workflow) before installing gdal. .github/workflows/gh-pages.yml [37-38] -pip install setuptools wheel numpy +pip install -U setuptools wheel numpy pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" Suggestion importance[1-10]: 4 __ Why: Upgrading setuptools/wheel before installing gdal can reduce sporadic build issues on runners, but the workflow already installs these tools so this is a smaller robustness improvement. The change is accurate and consistent with the approach used in python-test.yml.	Low

Suggestions up to commit efd0917

Category	Suggestion	Impact
Possible issue	Use only released Python versions 3.14 is not a released CPython version and will make the workflow fail to resolve the runtime. Use only supported versions (and keep intermediate versions like 3.11/3.13 if you intend to test them) to avoid CI breakage. .github/workflows/python-test.yml [25-26] matrix: - python-version: ["3.10", "3.12", "3.14"] + python-version: ["3.10", "3.11", "3.12", "3.13"] Suggestion importance[1-10]: 9 __ Why: Using 3.14 in actions/setup-python is very likely to fail because it is not a released CPython version, which can break CI entirely. Replacing it with released versions (e.g., 3.11/3.13) is a high-impact, correctness-focused fix.	High
	Make GDAL install reproducible Building gdal from source often requires numpy and can fail under pip build isolation, especially on newer Python versions. Mirror the other workflows by pre-installing build prerequisites and using --no-build-isolation so the bindings compile reliably against the system GDAL. .github/workflows/publish.yml [29-34] - name: Install apt dependencies run: | sudo apt-get update sudo apt-get -qq install exiftool libgdal-dev libzbar0t64 +- name: Install gdal python bindings + run: | GDAL_VERSION=$(gdal-config --version) - pip install "gdal==${GDAL_VERSION}" + pip install -U setuptools wheel numpy + pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" Suggestion importance[1-10]: 7 __ Why: Installing gdal via pip can fail due to build isolation and missing build prerequisites; aligning with the more robust approach used elsewhere (installing setuptools/wheel/numpy and using --no-build-isolation) improves CI reliability. The proposed change is relevant to the shown pip install "gdal==${GDAL_VERSION}" step and would likely reduce intermittent build failures.	Medium
	Restore default marker filtering Removing the default not newgdal filter can make CI fail when ubuntu-latest ships a GDAL version that doesn't satisfy the expectations of newgdal-marked tests. Keep excluding newgdal by default and run those tests in a dedicated job/environment that guarantees the newer GDAL stack. pyproject.toml [69-73] addopts = [ + "-m", + "not newgdal", "--cov=micasense", "--cov-report=xml", "--cov-report=term-missing", ] Suggestion importance[1-10]: 5 __ Why: Reintroducing -m "not newgdal" can prevent failures if newgdal-marked tests assume a newer GDAL stack than what ubuntu-latest provides. However, it may conflict with the PR’s intent to run those tests by default, so the impact is moderate and somewhat context-dependent.	Low

Suggestions up to commit e2b9119

Category	Suggestion	Impact
Possible issue	Fix unsupported Python version Python 3.14 is not a released/stable target and will likely make the CI job fail at environment setup. Test against currently supported versions (e.g., keep 3.13) and avoid dropping 3.11 unless intentionally de-supported. .github/workflows/python-test.yml [26] -python-version: ["3.10", "3.12", "3.14"] +python-version: ["3.10", "3.11", "3.12", "3.13"] Suggestion importance[1-10]: 7 __ Why: The matrix currently targets 3.14, which is likely unavailable/unstable in actions/setup-python and can break CI setup, while the project metadata still indicates support through 3.13. Re-adding 3.11/3.13 is a reasonable correction unless this PR intentionally moved to a pre-release test target.	Medium
	Relax GDAL version matching Installing gdal with an exact == match can fail when PyPI only has a different patch release than gdal-config --version. Use a compatible specifier (~=) so the bindings can resolve to the closest available patch version for the installed GDAL major/minor. .github/workflows/python-test.yml [42-44] GDAL_VERSION=$(gdal-config --version) pip install -U setuptools wheel numpy -pip install --no-cache-dir --no-build-isolation "gdal==$GDAL_VERSION" +pip install --no-cache-dir --no-build-isolation "gdal~=$GDAL_VERSION" Suggestion importance[1-10]: 4 __ Why: Using == for gdal==$GDAL_VERSION can indeed be brittle if the PyPI wheel version doesn’t exactly match the system gdal-config patch version. However, changing to ~=$GDAL_VERSION may still fail when PyPI only has an older patch than the system GDAL (since ~= won’t allow lower patch versions), so this is only a partial/uncertain fix.	Low

Suggestions up to commit cf2310f

Category	Suggestion	Impact
Possible issue	Ensure correct pip and fail fast Use python -m pip to ensure installs target the interpreter provisioned by actions/setup-python (especially important on runners with multiple Pythons). Also fail fast and make the version expansion safe by enabling strict shell mode and quoting GDAL_VERSION. .github/workflows/gh-pages.yml [36-38] -GDAL_VERSION=$(gdal-config --version) -pip install setuptools wheel numpy -pip install --no-cache-dir --no-build-isolation "gdal==$GDAL_VERSION" +set -euo pipefail +GDAL_VERSION="$(gdal-config --version)" +python -m pip install --no-cache-dir setuptools wheel numpy +python -m pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" Suggestion importance[1-10]: 5 __ Why: Switching to python -m pip and quoting GDAL_VERSION makes the install step more robust on runners with multiple Python/pip installations. Adding set -euo pipefail is a reasonable hardening, though GitHub Actions already runs bash with -e by default so the impact is moderate.	Low
General	Avoid source builds in CI Prevent CI from attempting to build numpy from source (which can fail or be very slow on runners) by forcing binary wheels. Keep the --no-build-isolation only on the GDAL install to preserve your intended build behavior. .github/workflows/python-test.yml [42-44] -GDAL_VERSION=$(gdal-config --version) -pip install setuptools wheel numpy -pip install --no-cache-dir --no-build-isolation "gdal==$GDAL_VERSION" +set -euo pipefail +GDAL_VERSION="$(gdal-config --version)" +python -m pip install --no-cache-dir --only-binary=:all: setuptools wheel numpy +python -m pip install --no-cache-dir --no-build-isolation "gdal==${GDAL_VERSION}" Suggestion importance[1-10]: 5 __ Why: Using --only-binary=:all: for setuptools wheel numpy can reduce CI time and avoid failures due to source builds, and keeping --no-build-isolation only for gdal matches the stated intent. However, forcing wheels can be slightly brittle if a wheel isn’t available for a future environment, so the benefit is moderate rather than critical.	Low

[github-actions]

Persistent review updated to latest commit e2b9119

[github-actions]

Persistent review updated to latest commit e2b9119

[github-actions]

Persistent review updated to latest commit efd0917

[github-actions]

Persistent review updated to latest commit 5c3773d