Skip to content

Removing newly introduced GDAL dependency (again) #336

Open
@karimbahgat

Description

@karimbahgat

Continuing the conversation from #332.

A recently introduced change added GDAL as a dependency to django-leaflet (see #299), resulting in a number of raised issues. In my opinion, there should be no reason to hang on to this dependency, it only hampers the ability of many users and light-weight applications which struggle or for other reasons cannot use GDAL,. Especially since django-leaflet as well as django-geojson has been touted and become known as lightweight packages that "just works" for non-gis users and simple websites (e.g. https://fle.github.io/easy-webmapping-with-django-leaflet-and-django-geojson.html, https://heds.nz/posts/leaflet-maps-django-geojson/). Opening this issue now to start the conversation on how this might be possible, before I can get around to a PR.

The only reason django-leaflet now requires GDAL is that it relies on GeometryField and BaseGeometryWidget from django.from django.contrib.gis. However, nothing about these classes uses anything of the actual GDAL library, it's only that importing from django.contrib.gis triggers a GDAL check. Previously, there was a fallback to a .nogeos.py or .backport.py module within django-leaflet which implemented the same classes but without requiring GDAL, but this was removed in #282 seemingly in the name of dropping support for Django < 1.8?

Unless I'm missing something here, when I get the time I will submit a PR that reintroduces the old fallbacks. Were there any other deeper reasons why the fallbacks were dropped?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions