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

Django Internals GeoDjango
1

I’d like to propose making a change to django.contrib.gis.gdal to enable lazy loading of the GDAL library, mirroring the existing behavior of django.contrib.gis.geos with the GEOS library. The GEOS module was made lazy 10 years ago (commit), but no one has bothered to do the same for the GDAL module in the time since then.

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 the GDAL just to be able to call django.setup() — GEOS isn’t required because of the laziness of its loading. Currently, calling setup on projects that use GeoDjango will fail if GDAL isn’t available, even when you’re not actually using any GDAL functionality.

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.

The good news is I have a pretty complete branch with a working POC, 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 compat (plus or minus a few scattered variables) but I’d like some feedback. So I’m creating this forum post to gauge interest before moving forward. I thought about opening a Trac ticket directly, but didn’t want to litter the tracker with it before seeing if people were interested in bringing GDAL to parity with GEOS in this regard.

4 Likes
2

Thanks Josh for this very promising work :+1:. I’m rather sympathetic to the idea, after a first look at the suggested commit.

Maybe you could now transform your commit in a real pull request, so we can run the full test suite to see how it looks.

1 Like
3

Thanks for doing the hard work for GEOS, made this patch largely grunt-work mimicking your prior changes. :smiling_face:

@CodenameTim suggested a new issue over in the django/new-features repo, so I may move the primary discussion over there.

I do think at this point it wouldn’t hurt to at least open the PR to see the full test suite run, especially since the core of the needed changes to functionally make this work is there. I just didn’t want to jump straight to it without at least firing a warning shot or two :rofl: – this is a pretty substantial change after all.

2 Likes
4

Issue created if anyone wants to give a :+1: to it.

5

For those interested, I have submitted a Trac ticket to track this as well.

1 Like
6

PR ready for review.