Open theroggy opened 1 month ago
Would it affect the number of available drivers?
Would it affect the number of available drivers?
Yes. I now inlined the list of dependencies that were moved to seperate packages above to get a detailed overview.
Most drivers are still available in libgdal-core, it is mainly dependencies that have a big hard-disk footprint that were moved to a seperate package. At least the drivers that are depended on in the pyogrio tests are all still available, I just tested this here: https://github.com/geopandas/pyogrio/pull/452
Comment:
The GDAL conda package has recently been revamped to seperate the core functionalities and a list of optional dependencies. It would be great if pyogrio users could have the advantages of this as well.
In practice a new
libgdal-core
package has been introduced, as well as a list of seperate packages with optional plugins. The oldlibgdal
depends on all the new packages to have backwards compatibility.The following optional GDAL dependencies were moved to seperate conda packages (reference https://github.com/conda-forge/gdal-feedstock/issues/722#issuecomment-2204537063):
If a user wants to read a file where one of these dependencies is needed but unavailable, they will get a clean error, and just have to install the appropriate extra package to get it working.
An important thing to note is that the new
libgdal-core
package is only available for GDAL 3.9.1 at this time. Unless I'm mistaken, this would lead to new versions of pyogrio to only be installable with GDAL 3.9.1?An alternative to avoid this could be to depend on the
gdal
package. This is the package that includes the GDAL python bindings, but the advantage is that for older versions this depends onlibgdal
and starting from 3.9.1 it depends onlibgdal-core
. This way it stays possible to install with an old GDAL.