You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Installing datapusher-plus on CKAN 2.12 fails at dependency resolution. Upstream ships 2.12 only as ckan/ckan-base:2.12-py3.14, and the exact pins in requirements.txt predate Python 3.14 wheels, so pip builds each from source and stops at the first one that needs native headers.
This is the same root cause as #334 (pandas 2.2.3 from source on 3.15), one interpreter version earlier. The pins are unchanged on main, so it applies to both the 2.x and 3.x lines.
Environment
CKAN 2.12.0 on ckan/ckan-base:2.12.0-py3.14 (Debian, Python 3.14)
datapusher-plus at 1825d62 (2.x line); main has the same four pins
qsv 5.1.0
Steps to reproduce
Start from ckan/ckan-base:2.12-py3.14.
pip install -r requirements.txt from datapusher-plus.
Expected behaviour
Dependencies resolve to wheels, as they do on Python 3.10-3.13.
Actual behaviour
pip downloads source tarballs and fails building them. First pyproj==3.7.1 (proj executable not found), and with PROJ present, fiona==1.10.1 (gdal-config not found; then cannot execute 'cc1plus' for fiona/_transform.cpp).
Wheel availability for the four pins, checked against PyPI on 15 September 2026:
pin
cp312
cp313
cp314
earliest release with a cp314 wheel
fiona==1.10.1
yes
yes
no
none - no fiona release has one
pandas==2.2.3
yes
yes
no
2.3.3
shapely==2.1.0
yes
yes
no
2.1.2
pyproj==3.7.1
yes
yes
no
3.7.2
What does install
With pandas==2.3.3, shapely==2.1.2 and pyproj==3.8.0 (all wheels), libgdal-dev and g++ in the image so fiona==1.10.1 compiles, and datapusher-plus installed with --no-deps, the image builds: datapusher-plus 2.0.0 alongside CKAN 2.12.0. I have not run it yet, so this shows only that the dependency set can resolve, not that datapusher-plus works on 2.12.
Would a pull request be welcome that relaxes the four pins to minimums (>=) and replaces fiona with pyogrio, which does ship cp314 wheels? The pin change is trivial. The pyogrio change touches the spatial file handling, so I would rather ask first. It would come with a CI matrix entry for 2.12/3.14, since the existing workflows would not otherwise exercise it.
Beyond installability, the change I expect to matter most on 2.12 is reading uploaded resources through the new configurable storage layer rather than a local filesystem path, since that is what lets datapusher-plus work when the filestore is not on local disk. Happy to contribute towards that as well if it is not already underway.
Summary
Installing datapusher-plus on CKAN 2.12 fails at dependency resolution. Upstream ships 2.12 only as
ckan/ckan-base:2.12-py3.14, and the exact pins inrequirements.txtpredate Python 3.14 wheels, so pip builds each from source and stops at the first one that needs native headers.This is the same root cause as #334 (pandas 2.2.3 from source on 3.15), one interpreter version earlier. The pins are unchanged on
main, so it applies to both the 2.x and 3.x lines.Environment
ckan/ckan-base:2.12.0-py3.14(Debian, Python 3.14)mainhas the same four pinsSteps to reproduce
ckan/ckan-base:2.12-py3.14.pip install -r requirements.txtfrom datapusher-plus.Expected behaviour
Dependencies resolve to wheels, as they do on Python 3.10-3.13.
Actual behaviour
pip downloads source tarballs and fails building them. First
pyproj==3.7.1(proj executable not found), and with PROJ present,fiona==1.10.1(gdal-confignot found; thencannot execute 'cc1plus'forfiona/_transform.cpp).Wheel availability for the four pins, checked against PyPI on 15 September 2026:
fiona==1.10.1pandas==2.2.3shapely==2.1.0pyproj==3.7.1What does install
With
pandas==2.3.3,shapely==2.1.2andpyproj==3.8.0(all wheels),libgdal-devandg++in the image sofiona==1.10.1compiles, and datapusher-plus installed with--no-deps, the image builds: datapusher-plus 2.0.0 alongside CKAN 2.12.0. I have not run it yet, so this shows only that the dependency set can resolve, not that datapusher-plus works on 2.12.Questions
prefect_enabledconfig option to run ingestions without Prefect #336 would also make 3.x runnable without Prefect, which changes the picture for deployments like ours that run an RQ-style worker today.)>=) and replaces fiona with pyogrio, which does ship cp314 wheels? The pin change is trivial. The pyogrio change touches the spatial file handling, so I would rather ask first. It would come with a CI matrix entry for 2.12/3.14, since the existing workflows would not otherwise exercise it.Beyond installability, the change I expect to matter most on 2.12 is reading uploaded resources through the new configurable storage layer rather than a local filesystem path, since that is what lets datapusher-plus work when the filestore is not on local disk. Happy to contribute towards that as well if it is not already underway.