Running unit tests on Mac takes me down a GDAL installation rabbit hole

[Ned Batchelder]

I wanted to run the unit tests on my Mac. I followed the instructions:

[:/src/django/nedbat/tests] master ± mkvirtualenv django
New python executable in django/bin/python
Installing setuptools, pip...done.
[:/src/django/nedbat/tests] [django] master ± pip install -r requirements/py2.txt
... many lines elided ...
Successfully installed bcrypt docutils jinja2 numpy Pillow PyYAML pytz selenium sqlparse python-memcached mock cffi six markupsafe pycparser
Cleaning up...
[:/src/django/nedbat/tests] [django] master ± PYTHONPATH=..:$PYTHONPATH ./runtests.py
Testing against Django installed in '/src/django/nedbat/django'
Traceback (most recent call last):
  File "./runtests.py", line 435, in <module>
    options.debug_sql)
  File "./runtests.py", line 239, in django_tests
    state = setup(verbosity, test_labels)
  File "./runtests.py", line 218, in setup
    apps.set_installed_apps(settings.INSTALLED_APPS)
  File "/src/django/nedbat/django/apps/registry.py", line 318, in set_installed_apps
    self.populate(installed)
  File "/src/django/nedbat/django/apps/registry.py", line 108, in populate
    app_config.import_models(all_models)
  File "/src/django/nedbat/django/apps/config.py", line 198, in import_models
    self.models_module = import_module(models_module_name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/src/django/nedbat/tests/gis_tests/models.py", line 10, in <module>
    from django.contrib.gis.db import models
  File "/src/django/nedbat/django/contrib/gis/db/models/__init__.py", line 5, in <module>
    from django.contrib.gis.db.models.aggregates import *  # NOQA
  File "/src/django/nedbat/django/contrib/gis/db/models/aggregates.py", line 1, in <module>
    from django.contrib.gis.db.models.fields import ExtentField
  File "/src/django/nedbat/django/contrib/gis/db/models/fields.py", line 4, in <module>
    from django.contrib.gis.gdal.raster.source import GDALRaster
  File "/src/django/nedbat/django/contrib/gis/gdal/raster/source.py", line 6, in <module>
    from django.contrib.gis.gdal.driver import Driver
  File "/src/django/nedbat/django/contrib/gis/gdal/driver.py", line 5, in <module>
    from django.contrib.gis.gdal.prototypes import ds as vcapi, raster as rcapi
  File "/src/django/nedbat/django/contrib/gis/gdal/prototypes/ds.py", line 9, in <module>
    from django.contrib.gis.gdal.libgdal import lgdal
  File "/src/django/nedbat/django/contrib/gis/gdal/libgdal.py", line 45, in <module>
    '", "'.join(lib_names))
django.contrib.gis.gdal.error.GDALException: Could not find the GDAL library (tried "gdal", "GDAL", "gdal1.11.0", "gdal1.10.0", "gdal1.9.0", "gdal1.8.0", "gdal1.7.0"). Try setting GDAL_LIBRARY_PATH in your settings.

A quick look at how to install gdal lead to scary pages, and a requirement to install GEOS, etc.

Looking at tests/gis_tests/models.py, it looks like it's trying to neuter itself if the GIS requirements aren't installed, but I guess it isn't doing it well enough?

I'd be glad to hack on making this better if someone could guide me on the philosophy to follow.

[Tim Graham]

Oops, that broke in a patch committed yesterday. I'll ping the author and ask him to take a look.

[Daniel Wiesmann]

Here is a possible solution, I think the RasterField needs to be imported separately from the geometry fields, as it depends on gdal but the geom fields can be used with only geos as well. So the proposed patch splits the GIS fields modlue in submodules.

​https://github.com/django/django/pull/4905

[Tim Graham]

Let's just reference the original ticket when committing this.

[Ned Batchelder]

You've marked this ticket as a duplicate of a closed ticket? What will track the work to fix the problem?

[Tim Graham]

We could reopen the original ticket, but don't worry, the pull request won't get lost.

[Ned Batchelder]

I didn't make a pull request for this...?

[Baptiste Mispelon]

Replying to nedbat:

I didn't make a pull request for this...?

Tim is talking about ​https://github.com/django/django/pull/4905

[Carl Meyer]

It's not a big deal, and I'm sure it's true that the PR won't get lost, but I think Ned is right, and there wasn't a good reason to close this ticket as a duplicate (especially as a duplicate of a ticket it clearly isn't a duplicate of - "problem caused by fix for some other ticket" is not the same thing as "duplicate").

If there's a known problem in master (which there is right now), a ticket with a clear description of that problem (which this is) should be left open until a fix for the problem is merged to master. And that fix should reference the ticket which is a clear description of the problem it's fixing (and perhaps also the original ticket whose fix caused the problem in the first place.)

[Tim Graham <timograham@…>]

In c0fff64:

Fixed #25011, Refs #23804 -- Added check for GDAL on RasterField initialization