rocker-versioned2
rocker-versioned2 copied to clipboard
rocker-org
Strategies for increasing availability of prebuilt images with latest GDAL?
Picking up from the discussion in #692:
It would be nice to consider strategies for making the latest GDAL version available more widely (e.g. perhaps on the rocker/binder derived images).
Currently this is straight forward using the recipe already used by rocker/geospatial:dev-osgeo:
RUN /rocker_scripts/experimental/install_dev_osgeo.sh
(where users can choose GDAL/GEOS/PROJ versions by setting env vars or getting the latest release by default). However, this recipe also involves switching installs away from the re-built PPM binaries to install from source, since binaries are built against the older LTS-packages versions of these libs and thus incompatible.
It seems a bit of a shame to give up binary installs across the board just to use the latest GDAL, so I'm wondering if there are other solutions? (Yes, I know I'm reinventing the wheel here because debian:sid exists to provide bleeding edge prebuilt binaries, but it would be nice to have an option that builds on the widely used ubuntu LTS base we have in the 'versioned' stack here).
Just wanted to check-in to see if there's anything more that has happened here?
#708 updates rocker/geospatial:dev-osgeo image to ship with a bit more extensive support for the latest GDAL/GEOS/PROJ.
Derivative dockerfiles can opt-in to this recipe, e.g. by: (as ROOT)
RUN /rocker_scripts/experimental/install_dev_osgeo.sh
and should then be good to go. I don't think we have an option to enable post-build-time for a non-root user at the moment. Would be good to better understand how well the above solution meets current needs and what use cases are not well served (i.e. if there's demand for some kind of opt-in to latest gdal as non-root user).
Also, more work is needed to understand if/when python libs will see these GDAL/GEOS/PROJ versions vs ship with their own. (Guessing that just means whether or not a user installs with pip from source or some other way.... maybe we should be doing this to build some latest-gdal-python-binaries like we do there for the corresponding R binaries.