Lazy loading for `django.contrib.gis.gdal`

[joshuadavidthomas]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Enable lazy loading of the GDAL library in django.contrib.gis.gdal, mirroring the existing behavior of django.contrib.gis.geos with the GEOS library.

Problem

Currently, calling django.setup() on projects that use GeoDjango will fail if GDAL isn't available, even when you're not actually using any GDAL functionality. GEOS doesn't have this problem because it was made lazy 10 years ago (commmit), but no one has bothered to do the same for the GDAL module in the time since then.

This creates an inconsistency in the GeoDjango framework where one geospatial library is lazy and the other isn't.

Request or proposal

proposal

Additional Details

This came about while I've been puttering around on my django-language-server side-project. I have a few applications that use the GeoDjango framework, and to get around the slight inconvenience of installing all the geospatial requirements locally, we moved to using a Docker container with them all pre-installed for development.

This works great for the actual applications, however, I want to be able to run the language server globally on my system without requiring Docker or having to install GDAL just to be able to call django.setup() — GEOS isn't required because of the laziness of its loading.

I initially tried working on a third-party library to prove this out (django-lazy-gdal), but the headache of trying to both lazily load GDAL and monkeypatch everything that needs patching has proven to be too complex to be worth banging my head against that wall anymore.

Implementation Suggestions

I have a pretty complete branch with a working POC (main branch diff), largely inspired by that original commit that made GEOS lazy. What's there is working just like it should, lazily loading the GDAL library while also mostly maintaining backwards compatibility (plus or minus a few scattered variables), but I'd like some feedback on the approach before moving forward with a formal pull request. Since this is a pretty substantial change, I wanted to gauge interest and gather feedback first.

Forum post

[github-actions]

Thank you joshuadavidthomas for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[claudep]

👍 FWIW. However, I'm not seeing this as an addition, but more as an optimization.

[joshuadavidthomas]

I know this has only been open a few days, and I’m not sure of the protocol around whether a feature/improvement needs the steering council to weigh in. Given that this is a brand new process and the steering council hasn’t met since opening it, I’m unsure if I should wait for that.

However, since I already have a branch ready for a PR and haven’t seen any negative reactions yet (all thumbs up so far), would it be alright to go ahead and at least open a draft PR to start gathering feedback?

[carltongibson]

I've advanced it @joshuadavidthomas — it looks like a straightforward optimisation, as @claudep noted. 👍

(Probably a ticket and a moving on again to In Progress is actually called for)

[joshuadavidthomas]

Just submitted a ticket to Trac.