#36441: Add lazy loading support for GDAL library in `django.contrib.gis.gdal`
-------------------------------------+-------------------------------------
Reporter: Josh Thomas | Owner: Josh
Type: | Thomas
Cleanup/optimization | Status: assigned
Component: GIS | Version: dev
Severity: Normal | Resolution:
Keywords: gdal | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> I'd like to propose enabling lazy loading of the GDAL library in
> `django.contrib.gis.gdal`, matching the existing behavior of
> `django.contrib.gis.geos` with the GEOS library.
>
> Currently, calling `django.setup()` on projects using GeoDjango fails if
> GDAL is not installed, even when GDAL functionality is not being used.
> This creates an inconsistency in the GeoDjango framework where the GEOS
> library supports lazy loading (implemented ~10 years ago) but GDAL does
> not. The proposed change would implement lazy loading for the GDAL module
> similar to the existing GEOS implementation, ensuring the GDAL library is
> only loaded when actually accessed or used.
>
> I have a working proof-of-concept in a
> [https://github.com/joshuadavidthomas/django/tree/lazy-gdal branch] on my
> fork of the Django repo ready for review
> ([https://github.com/django/django/compare/main...joshuadavidthomas:django
> :lazy-gdal diff]).
>
> The implementation follows the same approach as the original GEOS lazy
> loading commit, wrapping the library loading in `SimpleLazyObject` and
> converting function prototypes to use lazy loading. The public API
> remains unchanged (everything imported in
> `django/contrib/gis/gdal/__init__.py` continues to work as before),
> though the imports related to the GDAL version from
> `django.contrib.gis.gdal.libgdal` now use lazy evaluation. The existing
> test suite passes without modification, and I've added new tests
> specifically for the lazy loading behavior. Documentation updates have
> not been included yet as I wasn't sure if that was needed for a change
> like this.
>
> I have created both a [https://forum.djangoproject.com/t/proposal-lazy-
> loading-for-django-contrib-gis-gdal/41198 forum post] and an
> [https://github.com/django/new-features/issues/42 issue on django/new-
> features]. Both have only been open for a few days, so not a ton of time
> for people to see them. However, the initial reception has been positive,
> with the forum post receiving several likes and the new-features issue
> getting only thumbs-up reactions.
New description:
I'd like to propose enabling lazy loading of the GDAL library in
`django.contrib.gis.gdal`, matching the existing behavior of
`django.contrib.gis.geos` with the GEOS library.
Currently, calling `django.setup()` on projects using GeoDjango fails if
GDAL is not installed, even when GDAL functionality is not being used.
This creates an inconsistency in the GeoDjango framework where the GEOS
library supports lazy loading (implemented in 2015 in
61d09e61f5747d7a70268ca8d5e770486877500b) but GDAL does not. The proposed
change would implement lazy loading for the GDAL module similar to the
existing GEOS implementation, ensuring the GDAL library is only loaded
when actually accessed or used.
I have a working proof-of-concept in a
[https://github.com/joshuadavidthomas/django/tree/lazy-gdal branch] on my
fork of the Django repo ready for review
([https://github.com/django/django/compare/main...joshuadavidthomas:django
:lazy-gdal diff]).
The implementation follows the same approach as the original GEOS lazy
loading commit, wrapping the library loading in `SimpleLazyObject` and
converting function prototypes to use lazy loading. The public API remains
unchanged (everything imported in `django/contrib/gis/gdal/__init__.py`
continues to work as before), though the imports related to the GDAL
version from `django.contrib.gis.gdal.libgdal` now use lazy evaluation.
The existing test suite passes without modification, and I've added new
tests specifically for the lazy loading behavior. Documentation updates
have not been included yet as I wasn't sure if that was needed for a
change like this.
I have created both a [https://forum.djangoproject.com/t/proposal-lazy-
loading-for-django-contrib-gis-gdal/41198 forum post] and an
[https://github.com/django/new-features/issues/42 issue on django/new-
features]. Both have only been open for a few days, so not a ton of time
for people to see them. However, the initial reception has been positive,
with the forum post receiving several likes and the new-features issue
getting only thumbs-up reactions.
History: GDAL was initially (inadvertently) required before it was made
optional in #5433 and then was made required in #26753 in order to simply
the code base.
--
Comment (by Tim Graham):
I don't know about that proposal. It seems strange to have to silence
warnings for "optional dependencies" that may not be needed. I would like
to see my questions in comment:13 answered in order to understand how a
"missing GDAL" error would be surfaced to a user.
By the way, despite the lazy loading commit for GEOS, it's
[https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/geolibs
/#geospatial-libraries still listed as a required dependency]. I guess not
much of GeoDjango is usable without it.
--
Ticket URL: <https://code.djangoproject.com/ticket/36441#comment:16>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019a18cea2a8-89b63cd1-df56-4a12-9f7f-5e596f9f4f3a-000000%40eu-central-1.amazonses.com.
