django / django/new-features

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

Open
#42 6 comments 16 reactions 0 assignees View on GitHub
Django Core GeoDjango
Dominant language
No language data
Stars
188
Forks
7
PR merge metrics
No merged PRs in 30d

Description

### Code of Conduct

- [x] 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](https://github.com/django/django/commit/61d09e61f5747d7a70268ca8d5e770486877500b)), 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](https://github.com/joshuadavidthomas/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](https://github.com/joshuadavidthomas/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](https://github.com/joshuadavidthomas/django/tree/lazy-gdal) with a working POC (main branch [diff](https://github.com/django/django/compare/main...joshuadavidthomas:django:lazy-gdal)), 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](https://forum.djangoproject.com/t/proposal-lazy-loading-for-django-contrib-gis-gdal/41198)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.