#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
-------------------------------------+-------------------------------------
Comment (by Jacob Walls):
I doubt anything is more logically special about GDAL over GEOS in this
regard, but we do have this
[https://docs.djangoproject.com/en/5.2/releases/1.11/#id1 language] from
the Django 1.1 release saying it's required to use GeoDjango:
> To simplify the codebase and because it’s easier to install than when
contrib.gis was first released, GDAL is now a required dependency for
GeoDjango. In older versions, it’s only required for SQLite.
The complicated mechanism for detecting whether GDAL was present was
removed in #28160.
Is GEOS any different? I don't know. It sounds like it's required from
reading
[https://docs.djangoproject.com/en/5.2/ref/contrib/gis/install/#requirements
GeoDjango requirements]. I don't get the sense that either of them are
optional.
A system check to catch misconfiguration is in the spirit of the
contrib.postgres check from #32770. I still think I would miss it if the
current proposal takes away the eager imports.
>Also consider that it's possible to use aspects of GeoDjango that rely on
GEOS and GDAL without using the model fields.
I agree -- this should probably just be a system check registered at the
`contrib.gis` app level, not field level.
----
Given that we didn't have a check for GEOS, I can relent on blocking this
work over it if no one else thinks it's important. I only have the
anecdotal evidence that it was only ever the GDAL installation that gave
me trouble. (Thanks, HomeBrew?🍺)
Also anecdotal, but on the project forum for the software I used to work
on, the user support requests
[https://community.archesproject.org/search?q=GDAL_LIBRARY_PATH also
seemed to be about 2x for configuring GDAL] vs GEOS, but I acknowledge
that's a supremely small sample size...
I think a system check at the app level makes sense to ship in the same
release we are doing this other work. If Josh is up for it, I think it
makes sense to tag along now as a `Refs #...` commit. Otherwise I can pick
it up.
--
Ticket URL: <https://code.djangoproject.com/ticket/36441#comment:14>
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/0107019a18503be7-dc64c515-a71d-4490-b4c6-acb854e53d11-000000%40eu-central-1.amazonses.com.
