Hi Sean On Thu, 16 Nov 2023 at 12:10, Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote:
> > > > I think this makes great sense for the project. I don't yet understand > > what it means for an enterprise like Rasterio's PyPI wheels. > > I'd say it probably changes nothing. The RFC just postpones the time > where the plugins are loaded, but the fact that they are dlopen()'ed > (early or late) probably makes them non discoverable by delocate, since > libgdal doesn't link to them in a way that is advertised in its shared > library metadata. If your plan is to still have a rasterio wheel with a > monolithic GDAL, then you don't need to build GDAL drivers as plugins > and this RFC doesn't change anything to the status quo. > > I'm not familiar at all with the wheel Python packaging tools, but if > you'd want to have GDAL plugins in separate package(s) then you'd need > to have a way of having the gdal_XXX.so / ogr_XXX.so be put in some > known location that can be advertized to libgdal core with > GDAL_DRIVER_PATH. > PyInstaller has a set of hooks for this, where custom behaviour can be scripted for packages that need it. AFAICS auditwheel & delocate don't, and also don't have `--include=my.so` options to override it and "force" libraries to be processed — the same issue crops up for stuff using ctypes IIUC. My horrible workaround idea: building a shim _gdalplugins python module which does nothing except link to all the plugin libraries — that would allow them all to be processed by delocate/auditwheel alongside the real libgdal — so you get libgdal, and all the driver plugin libraries, and their dependencies. Since _gdalplugins is never used/loaded (ideally it'd be dropped) gdal would work via runtime plugin loading. The library renaming that auditwheel/delocate do might get in the way, but hopefully there's a path through that. Cheers, Rob :)
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev