Opened 9 years ago

Closed 9 years ago

#25011 closed Cleanup/optimization (fixed)

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

Reported by: Ned Batchelder Owned by: nobody
Component: Testing framework Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (10)

comment:1 by Tim Graham, 9 years ago

Triage Stage: UnreviewedAccepted
Version: 1.8master

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

comment:2 by Daniel Wiesmann, 9 years ago

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

comment:3 by Tim Graham, 9 years ago

Resolution: duplicate
Status: newclosed

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

Version 0, edited 9 years ago by Tim Graham (next)

comment:4 by Ned Batchelder, 9 years ago

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

comment:5 by Tim Graham, 9 years ago

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

comment:6 by Ned Batchelder, 9 years ago

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

in reply to:  6 comment:7 by Baptiste Mispelon, 9 years ago

Replying to nedbat:

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

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

comment:8 by Carl Meyer, 9 years ago

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.)

comment:9 by Aymeric Augustin, 9 years ago

Resolution: duplicate
Status: closednew

comment:10 by Tim Graham <timograham@…>, 9 years ago

Resolution: fixed
Status: newclosed

In c0fff64:

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

Note: See TracTickets for help on using tickets.
Back to Top